text:
🛑 TROJAN 🇸🇬 Singapore SGA 1 is down

In c26b2d2, TROJAN 🇸🇬 Singapore SGA 1 (https://sgt-3.opensvr.net/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TROJAN 🇸🇬 Singapore SGA 1 is back up in 08b8c38.

repo: roosterkid/opentunnel-status-server


text:
🛑 TROJAN 🇺🇸 United States USO 1 is down

In 6a1fea3, TROJAN 🇺🇸 United States USO 1 (https://ust-2.opensvr.net/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TROJAN 🇺🇸 United States USO 1 is back up in 3d3cabf.

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 TROJAN 🇺🇸 United States USO 1 is down

In 17198bd, TROJAN 🇺🇸 United States USO 1 (https://ust-2.opensvr.net/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TROJAN 🇺🇸 United States USO 1 is back up in 3487fed.


text:
🛑 V2RAY 🇸🇬 Singapore SGO 2 is down

In 03e268a, V2RAY 🇸🇬 Singapore SGO 2 (https://sgv-2.openv2ray.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: V2RAY 🇸🇬 Singapore SGO 2 is back up in 1f411ea.


text:
🛑 V2RAY 🇮🇩 Indonesia IDG 1 is down

In c9545d9, V2RAY 🇮🇩 Indonesia IDG 1 (https://idv-2.openv2ray.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: V2RAY 🇮🇩 Indonesia IDG 1 is back up in afae033.


text:
🛑 TROJAN 🇮🇩 Indonesia IDJ 1 is down

In 45951e4, TROJAN 🇮🇩 Indonesia IDJ 1 (https://idt-1.opensvr.net/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TROJAN 🇮🇩 Indonesia IDJ 1 is back up in aa3941e.


text:
🛑 TROJAN 🇭🇰 Hong Kong HKE 1 is down

In db7d32d, TROJAN 🇭🇰 Hong Kong HKE 1 (https://hkt-1.opensvr.net/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TROJAN 🇭🇰 Hong Kong HKE 1 is back up in 0c1d535.


text:
🛑 SSH 🇩🇪 Germany DEH 1 is down

In de3dd95, SSH 🇩🇪 Germany DEH 1 (http://des-1.opensvr.net:8080/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SSH 🇩🇪 Germany DEH 1 is back up in a32685a.


text:
🛑 XRAY 🇮🇩 Indonesia IDA 1 is down

In b0a7d0f, XRAY 🇮🇩 Indonesia IDA 1 (https://idx-1.openv2ray.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: XRAY 🇮🇩 Indonesia IDA 1 is back up in 860d699.


text:
🛑 SSH 🇫🇷 France FRO 1 is down

In 1e10a57, SSH 🇫🇷 France FRO 1 (http://frs-1.opensvr.net:8080/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SSH 🇫🇷 France FRO 1 is back up in 74c85ff.


text:
🛑 SSH 🇮🇩 Indonesia IDJ 1 is down

In c3e062e, SSH 🇮🇩 Indonesia IDJ 1 (http://ids-1.opensvr.net:8080/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SSH 🇮🇩 Indonesia IDJ 1 is back up in 9d3a425.


text:
🛑 OVPN 🇫🇷 France FRO 1 is down

In 44cb3a3, OVPN 🇫🇷 France FRO 1 (http://fro-1.opensvr.net:8080/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: OVPN 🇫🇷 France FRO 1 is back up in da12f04.


text:
🛑 TROJAN 🇮🇩 Indonesia IDJ 1 is down

In 8229e2b, TROJAN 🇮🇩 Indonesia IDJ 1 (https://idt-1.opensvr.net/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TROJAN 🇮🇩 Indonesia IDJ 1 is back up in d8e9a64.


text:
🛑 TROJAN 🇳🇱 Netherlands NLB 1 is down

In 6f8daea, TROJAN 🇳🇱 Netherlands NLB 1 (https://nlt-1.opensvr.net/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TROJAN 🇳🇱 Netherlands NLB 1 is back up in 7195504.


text:
🛑 SSH 🇨🇭 Switzerland CHI 1 is down

In 2ddf1df, SSH 🇨🇭 Switzerland CHI 1 (http://chs-1.opensvr.net:8080/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SSH 🇨🇭 Switzerland CHI 1 is back up in 21aea8a.


text:
Update componentWillMount to componentDidMount before the next major version of React Native

According to React Native 0.60:
componentWillMount is deprecated and will be removed in the next major version. Use componentDidMount instead. As a temporary workaround, you can rename to UNSAFE_componentWillMount.
See documentation here.
Edit: add link to React Native documentation

See PR #376

Could we get a fix for this? Seems like a simple change.

using patch-package to fix this for now

@usmansbk what is patch-package?

authors: Sumansourabh14 jeffraux tschempp-scs usmansbk

repo: root-two/react-native-drawer

license: mit

license_source: bigquery


text:
Update the documentation to Sage 10

[x] I've read the guidelines for Contributing to Roots Projects
[x] This request isn't a duplicate of an existing request
[x] This is not a personal support request that should be posted on the Roots Discourse community

Summary
The current documentation is only up to v9.x. Since the master branch is now 10.x it's handy to update the documentation.
Motivation
For future developers to catch any issues beforehand by reading the documentation in the corresponding version.

thanks @basduchambre - we're tracking this over at https://github.com/roots/sage/issues/2357
the current progress can be seen at https://github.com/roots/docs/pull/249

authors: basduchambre retlehs

repo: roots/sage


text:
TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/49137

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/49518

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/49951

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/50496

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/50505

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/50586

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/50590

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/50653

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/50659

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/59880

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/70774

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/70782

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/73220

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/75344


text:
Value error, likely due to missing fields in the NMEA message. Error was: 'utf-8' codec can't decode

On ROS humble, I get the following when I run ros2 launch theia_localization nmea_serial_driver.launch.py
[nmea_serial_driver-1] [INFO] [1698850685.891022741] [nmea_navsat_driver]: Successfully connected to /dev/ttyACM0 at 4800. [nmea_serial_driver-1] [WARN] [1698850686.079509490] [nmea_navsat_driver]: Value error, likely due to missing fields in the NMEA message. Error was: 'utf-8' codec can't decode byte 0xb5 in position 0: invalid start byte.

Did you figure this out yet?

No

0xb5 is not a valid character values for ASCII (or even UTF-8). NMEA sentences may only contain ASCII characters. If you're getting this byte from your device, it means one of three things:

Your device outputs invalid data containing non-ASCII characters, and therefore is not producing valid NMEA sentences. (Unlikely.)
Your serial port's baud rate is not set the same as your device, which is causing the serial port to produce garbage data.
This is a transient error that only occurs when the serial port first connects, in which case it can be ignored.

authors: ashBabu brjthomas evenator


text:
Add CacheManager tests.

Adds testing for CacheManger.py.
$ coverage run --source=superflore -m nose && coverage report -m
..................................................
----------------------------------------------------------------------
Ran 50 tests in 13.437s

OK
Name                                               Stmts   Miss  Cover   Missing
--------------------------------------------------------------------------------
superflore/CacheManager.py                            20      0   100%
superflore/PackageMetadata.py                         22      0   100%
superflore/TempfileManager.py                         34      6    82%   48-56
superflore/__init__.py                                10      4    60%   5-8
superflore/docker.py                                  51     12    76%   40, 54-67, 77, 80-81
superflore/exceptions.py                              18      3    83%   28, 33, 38
superflore/generate_installers.py                     63      0   100%
superflore/generators/__init__.py                      0      0   100%
superflore/generators/bitbake/__init__.py              3      1    67%   3
superflore/generators/bitbake/gen_packages.py        102     79    23%   40-122, 129-168, 175-183, 189
superflore/generators/bitbake/ros_meta.py             27     18    33%   24-27, 30-35, 38-51, 54-55
superflore/generators/bitbake/run.py                 113     90    20%   43-187
superflore/generators/bitbake/yocto_recipe.py        120    100    17%   44-67, 70, 73-77, 80-92, 95-99, 102-104, 107-108, 116-119, 128-187
superflore/generators/ebuild/__init__.py               3      1    67%   3
superflore/generators/ebuild/ebuild.py               185     19    90%   96-99, 126-131, 146, 176-180, 186, 193, 206-210
superflore/generators/ebuild/gen_packages.py         140    113    19%   46-119, 125-137, 143-188, 193-210, 213, 216
superflore/generators/ebuild/metadata_xml.py          33      0   100%
superflore/generators/ebuild/overlay_instance.py      35     24    31%   26-31, 34-45, 50-69, 72-73
superflore/generators/ebuild/run.py                  121     95    21%   48-188, 192-196
superflore/parser.py                                  13      0   100%
superflore/repo_instance.py                           70     51    27%   29-49, 56-65, 68-76, 82-83, 89, 95-96, 102, 105-120, 123
superflore/rosdep_support.py                          34      2    94%   83-84
superflore/test_integration/__init__.py                0      0   100%
superflore/test_integration/gentoo/__init__.py         3      1    67%   3
superflore/test_integration/gentoo/build_base.py      26     17    35%   26-28, 33, 38-50
superflore/test_integration/gentoo/main.py            30     24    20%   26-71
superflore/utils.py                                  189     67    65%   50-56, 60-63, 67-82, 86-97, 101-104, 114, 174, 191-194, 196, 202, 208-209, 214, 218-219, 226-247
--------------------------------------------------------------------------------
TOTAL                                               1465    727    50%

50% coverage!

source: gharchive/pull-request

repo: ros-infrastructure/superflore


text:
yocto_recipe.py: don't create cache.yaml and cache.diffme (#252)

ros-generate-cache.sh already does that and superflore then just
generates recipes from cache.yaml file updated by
ros-generate-cache.sh
fixes: https://github.com/ros-infrastructure/superflore/issues/252
needs: https://github.com/ros/meta-ros/pull/643

Signed-off-by: Martin Jansa martin.jansa@lge.com

The cache.yaml that ros-generate-cache generated is only used by superflore ifROSDISTRO_INDEX_URL is in its environment => if it isn't, it should continue to generate cache.diffme.

So you want to keep this block and only call yoctoRecipe.generate_distro_cache(_repo, args.ros_distro) conditionally on ROSDISTRO_INDEX_URL being set? I don't mind changing that, but then the sed replacements will be in 2 places (ros-generate-cache.sh and superflore/generators/bitbake/yocto_recipe.py) and with ros-generate-recipes.sh always setting ROSDISTRO_INDEX_URL I wasn't expecting anyone to not use that.

sed replacements will be in 2 places

What I've done in the past to handle this is add a comment in each place that tells the reader making a change the other place that also needs to be updated.

with ros-generate-recipes.sh always setting ROSDISTRO_INDEX_URL I wasn't expecting anyone to not use that.

Then superflore-gen-oe-recipes should fail if ROSDISTRO_INDEX_URL  isn't set to make sure that no one uses it by itself. It seems like it would be more flexible not require that, though.

sed replacements will be in 2 places

What I've done in the past to handle this is add a comment in each place that tells the reader making a change the other place that also needs to be updated.

with ros-generate-recipes.sh always setting ROSDISTRO_INDEX_URL I wasn't expecting anyone to not use that.

Then superflore-gen-oe-recipes should fail if ROSDISTRO_INDEX_URL isn't set to make sure that no one uses it by itself. It seems like it would be more flexible not require that, though.

If you don't want to use cache.yaml and rosdistro files stored in meta-ros (e.g. completely ignore ros-generate-cache.sh part), then you can still call superflore directly and it works (I've just tried to regen eloquent from latest index). We shouldn't accept such change to meta-ros, because it didn't correctly update the cache.yaml nor cache.diffme (and was created with unknown rosdistro mapping), but it still might be useful for someone locally (e.g. to see what's different in latest index without updating cache and rosdistro in meta-ros), why should we make ROSDISTRO_INDEX_URL mandatory like ros-generate-recipes.sh does?

it still might be useful for someone locally (e.g. to see what's different in latest index without updating cache and rosdistro in meta-ros

OK. I withdraw my request.

@allenh1 < Ready to merge.

authors: herb-kuta-lge shr-project


text:
[dunfell][gatesgarth][hardknott][honister] {noetic} Upgrade 2021-06-25 release

https://discourse.ros.org/t/new-packages-for-noetic-2021-06-25/21091

Merged to other branches as well:
67fd21d38..1a203ce05  dunfell -> dunfell-next
6e104d2b5..7052c245c  gatesgarth -> gatesgarth
6e104d2b5..7052c245c  gatesgarth -> gatesgarth-next
e065f048f..07c6fb891  hardknott -> hardknott
e065f048f..07c6fb891  hardknott -> hardknott-next
9a88718d9..e1a6ad29a  master -> master
9a88718d9..e1a6ad29a  master -> master-next

repo: ros/meta-ros


text:
Missing rosdep key for ament_cmake_clang_tidy

Hello.
I had a package relying on ament_cmake_clang_tidy but that key is not present in rosdistro. Looking around to see which packages use it, the only recent example was here.
The error:
Cannot locate rosdep definition for [ament_cmake_clang_tidy]
ROS Version: Galactic
Is there a reason this is not present as a rosdep key  in this repo or other reason it cannot be found?

If I understand the index correctly, the rosdep package would be ament_lint, as per https://github.com/ros/rosdistro/blob/master/galactic/distribution.yaml#L156
Note that it pulls in multiple other packages in tow, but I think it's a [possibly intentional] limitation of rosdep when dealing with multiple packages originating from the same repository.

ament_cmake_clang_tidy is a ROS package, not a rosdep key. It looks like it is present in ROS Galactic. https://github.com/ament/ament_lint/tree/galactic/ament_cmake_clang_tidy
The error message you posted looks like rosdep was unable to find the package ament_cmake_clang_tidy, and then looked it up as a rosdep key and was unable to find it that way too. There's not enough context for me to reproduce it. Mind providing a minimal reproducible example?
Does the issue persist after rosdep update?

authors: RFRIEDM-Trimble mjbogusz sloretz

repo: ros/rosdistro


text:
Add BigTree to rosdistro?

Currently for tree traversal, only anytree is listed in rosdistro: https://github.com/ros/rosdistro/blob/90d0bca39afdad90a70f04a1655b565a60bed7cd/rosdep/python.yaml#L6026
I find it a bit limited and am interested in using bigtree. Would this be possible or the maintainers need to agree to this? Sorry for my lack of knowledge about this.

If you would like to add a key to rosdep, please follow the contributing guide for rosdep keys here: https://github.com/ros/rosdistro/blob/master/CONTRIBUTING.md#rosdep-rules-contributions

authors: ipa-hsd mjcarroll


text:
fanuc: disable Kinetic experimental repository devel jobs

As per subject.

Thanks for the suggestion @tfoote.


text:
Add libqt5serialport5-dev

Add support for the dev version of libqt5serialport5

Looks like
Debian (Jessie to Buster): https://packages.debian.org/bullseye/libqt5serialport5-dev
Ubuntu (Xenial to Focal): https://packages.ubuntu.com/focal/libqt5serialport5-dev
Fedora https://fedora.pkgs.org/32/fedora-x86_64/qt5-qtserialport-devel-5.13.2-2.fc32.i686.rpm.html
In addition, there is a Gentoo package https://packages.gentoo.org/packages/dev-qt/qtserialport
Please confirm and add Gentoo if that's the correct one.

Looks like
Debian (Jessie to Buster): https://packages.debian.org/bullseye/libqt5serialport5-dev
Ubuntu (Xenial to Focal): https://packages.ubuntu.com/focal/libqt5serialport5-dev
Fedora https://fedora.pkgs.org/32/fedora-x86_64/qt5-qtserialport-devel-5.13.2-2.fc32.i686.rpm.html
In addition, there is a Gentoo package https://packages.gentoo.org/packages/dev-qt/qtserialport
Please confirm and add Gentoo if that's the correct one.

No response in over a month, so I'm going to close this.  Please feel free to respond to the review comments and reopen.  Thanks for the contribution.

authors: carebare47 clalancette mabelzhang


text:
Update rosdep only once during migration

Leverage ros-infrastructure/bloom#565 to prevent automatic calls to rosdep update by Bloom, but perform one explicit update at the start.
This should make the process substantially faster.

Nice!

authors: cottsay nuclearsandwich


text:
Add odrive pip package

Please add the following dependency to the rosdep database.
Package name:
pip/pip3 odrive
Package Upstream Source:
https://github.com/odriverobotics/ODrive
Purpose of using this:
This dependency is used for interacting with the ODrive brushless DC motor control boards.
Links to Distribution Packages

Pip: https://pypi.org/project/odrive/

Sorry merging one of the other PRs messed this one up. @igor-markovic can you please resolve the conflict?

No worries, all done. Thanks

authors: igor-markovic wjwwood


text:
find_object_2d: 0.7.1-2 in 'jazzy/distribution.yaml' [bloom]

Increasing version of package(s) in repository find_object_2d to 0.7.1-2:

upstream repository: https://github.com/introlab/find-object.git
release repository: https://github.com/ros2-gbp/find_object_2d-release.git
distro file: jazzy/distribution.yaml
bloom version: 0.12.0
previous version for package: 0.7.0-6

Holding for Jazzy sync

authors: christophebedard matlabbe


text:
Implemented Sketch to Render Use Case

Implemented:

switching between Drawing View and Render View
Letting the user enter a description and get a render of their sketch

I've added the tests.


text:
Fix type exports

This fixes typescript error TS7016:

Could not find a declaration file for module 'aes-cmac'. '/projectDir/node_modules/.pnpm/aes-cmac@3.0.2/node_modules/aes-cmac/lib/aes-cmac.mjs' implicitly has an 'any' type.
There are types at '/projectDir/node_modules/aes-cmac/lib/aes-cmac.d.ts', but this result could not be resolved when respecting package.json "exports". The 'aes-cmac' library may need to update its package.json or typings. ts(7016)

Thanks for the PR, @lvogt! Would you be able to provide a minimal example that reproduces the issue? I’ll add it to the test set.

ts-7016-issue.zip
Hi this seems to be more or less as minimal as it gets. VSCode already highlights the issue and calling npm run compile (or npm exec tsc) also emits the error.

@lvogt thanks again, this is released in v3.1.0


text:
Integration tests

This is not ready to merge, but I wanted to open conversation on a proof of concept for how we might set up integration tests (re: #17).
TBH, I've never used Supertest or done much integration testing like this in JS before, but it seems to work. I'm very open to feedback on best practices or cleaning it up though!
I just added you as a collaborator on this airtable base, so you should be able to run the integration tests via the command line:
AIRTABLE_API_KEY=... AIRTABLE_BASE_ID=... npm test

If you leave out the API keys, it should skip the integration test suite file.
I'm excited about this, should make debugging easier and regressions less likely! 🎆

Great, thanks! Glad it was helpful.

@rosszurowski another round of updates in the books.
One other thing I thought about is that we can add the API Key and Base ID to Travis if you want to run the integration tests during CI. I can't think of a reason we would not want to do it, and in fact I could see it being very useful if other devs want to make updates who don't have access to our shared Airtable.

authors: karllhughes rosszurowski

repo: rosszurowski/micro-airtable-api


text:
Race name and date on finish page

Add a field to record the name of the race on the finish page.

Did not add date (it seemed redundant)

repo: rotor-rig/racebox


text:
Improve Shadows performance on Android

I just implemented a BitmapCache for Android shadows.
It means that every shadows with the same properties (Width/Height, Blur, Color, Opacity), share the same Bitmap instance.
It should greatly improve the performance of Shadows in the list view.
Could some of you can Beta-test and tell me if you see improvements, and/or regressions?
@themronion
@Jerome-Liger
Sharpnado.Shadows.1.2.0-pre1.nupkg.zip

Great, thanks !
I'll test it because we use the same shadows everywhere (in SfListView, CollectionView, Buttons, ContentViews,...)
I'll keep you in touch soon...

New beta package tested and.... awsome !!!
The list are a way far very smoothier :-D
You can include this BitmapCache in the next package release... it's a must have !
Thanks a lot for this improvement (I keep the pre-1 in my project from now ;-) )

Wow cool! I will believe you and Jerome that they are major improvements. Keep up the fantastic work and waiting for the release!

nah! dont wait for the release please test the nuget attached.
Add it in a local nuget repo:
https://www.c-sharpcorner.com/article/creating-a-local-nuget-package-repository/
And tell me all about it!

Oh okay, but the last time i tried a nuget it had issues on UWP, i forgot to tell u about them, the same issues as i fixed here #11, but i guess you erased my commented out lines with InternalLogger.Debug() and it breaked again. Can u please comment out those lines quickly or change all references to ActualSize and ActualOffset?

The improvement is just for Android.
Also I can see your code here: https://github.com/roubachof/Sharpnado.Shadows/blob/master/Shadows/Shadows.UWP/UWPShadowsController.cs
(no more ActualSize.X ...)
So it doesn't seem to be erased...

Yeah, but still there are references in the InternalLogger: https://github.com/roubachof/Sharpnado.Shadows/blob/33b7b301ce028037f8ad95e9d3a55e4023be6026/Shadows/Shadows.UWP/UWPShadowsController.cs#L162

argh or maybe this line:
InternalLogger.Debug(
LogTag,
$"shadowSource: {{ ActualOffset: {_shadowSource.ActualOffset}, ActualSize: {_shadowSource.ActualSize}, Margin: {_shadowSource.Margin} }}");

Yeah, yeah

Zob as we say in france you're right. Wait, I will make a new pre package

)) Merci!!

meanwhile i tested it out on android - works faster indeed!! ListViews scroll faster than Musk's rockets)

Thank you guys for tested it so quickly!

@themronion here is the correction for uwp.
Could you please validate ?
Sharpnado.Shadows.1.2.0-pre2.nupkg.zip

@roubachof  Nope((( Check the code, maybe there are still some references?

Could you give me the full exception stack ? cant see anymore reference in uwp code...

Nevermind, after a complete cleaning, deleting and rebuilding the project it started to work as a charm!! Thanks!

fixed by https://github.com/roubachof/Sharpnado.Shadows/releases/tag/v1.2.0

authors: Jerome-Liger roubachof themronion


text:
[MAUI] DelayedView LoadingTemplate or Loading Content?

Describe the solution you'd like
When pages loads with DelayedView a activity indicator shows but it would be nice to have an option to provide some other visual indicator of page loading like skeleton loading into a LoadingView?
Something like the following:
<tabs:DelayedView  Animate="True" UseActivityIndicator="False" ... >
                        <tabs:DelayedView.LoadingView>
                        <!--some loadingview or control template option?-->
                        </tabs:DelayedView.LoadingView>
</tabs:DelayedView>

Describe alternatives you've considered
Currently we use the the following that requires a bit more involvement of switching layout but ideally we could utilize DelayedView view switching and its improved performance, currently we still using LazyView
<Grid toolkit:StateContainer.CurrentState="{Binding CurrentPageState}">
                        <toolkit:StateContainer.StateViews>
                            <Grid
                                toolkit:StateView.StateKey="Loading"

indeed ! It should be really easy to implement with ControlTemplate, please make a PR!

indeed ! It should be really easy to implement with ControlTemplate, please make a PR!

As time permits, I will see what I can do.

https://github.com/user-attachments/assets/aa7d300c-ff65-4946-8c2b-69b55b0ac1df

Great! 💯

authors: LeoJHarris roubachof


text:
App using

Hi.
I'm the developer of Gitskarios: https://play.google.com/store/apps/details?id=com.alorma.github
I implemented this library in the app (on pull request screen), it will be released soon.
Will you add into the README?

Yes I will.
And good work, I love that app and use it daily!

:$ Thanks! I will send you an APK to test the BottomBar

authors: alorma roughike

repo: roughike/BottomBar


text:
DynamicInit support / ModList integration

The plugin should be updated to support runtime enabling/disabling, so it properly supports ModList when it releases.

Also important to resolve a bug with the Server Browser button breaking after saving mod settings.

A larger rewrite is in progress.

repo: roydejong/BeatSaberServerBrowser


text:
Avoid "accepted by the compiler, rejected by the preprocessor"

This should address https://github.com/rpki-client/rpki-client-portable/issues/38#issuecomment-806859098 according to my tests

Merged. I removed the CPPFLAGS not realizing that autoconf itself depends on CPPFLAGS :(

authors: cjeker robert-scheck

repo: rpki-client/rpki-client-portable

license: ISC


text:
🛑 dm.vern.cc is down

In 15dc0ce, dm.vern.cc (https://dm.vern.cc) was down:

HTTP code: 0
Response time: 0 ms

Resolved: dm.vern.cc is back up in d8f3f55 after 42 minutes.

repo: rramiachraf/dumb-instances


text:
W1070 starts blocking commands after some time

I've submitted pull request https://github.com/rrooggiieerr/benqprojector.py/pull/10 to get this projector functional with this library in home assistant, but I'm running into an inconsistent issue where the integration starts failing after some time (becomes unavailable / fails to set up after restart), and when I manually check projector I find that it has started blocking all commands:
$ telnet projector-esp-link.lan
Trying 192.168.1.96...
Connected to projector-esp-link.lan.
Escape character is '^]'.

>
*pow=?#
*pow=?#

*Block item#
^]
telnet> close
Connection closed.

Once in this state the projector needs to be turned on with the remote / IR blaster to start working again (power cycling didn't even seem to help - only turning it on fixed it), but I'm not yet positive what is triggering this - the power commands should work while the projector is off, and I haven't encountered this issue previously when I've manually controlled the projector over serial (though that could just be because I rarely did so and just got lucky when I did).
I'm wondering if you might have seen this issue before or have any thoughts as to what to try to resolve / further diagnose it?
Some possibilities I've wondered about are if the connection is being interrupted in the middle of a command could the projector get into a bad state? I'm using socat to create a virtual tty that connects to a Wemos D1 Mini over WiFi attached to a RS232 to TTL converter plugged into the serial port, so there are definitely some extra potential points of failure there compared to a direct serial connection that I've used in the past, and I did notice some timeouts when running the 'examine' command... Another thought is could benqprojector be querying a command that had a different meaning or was bugged on the W1070 and puts it into a bad state?
I recognise that this may just end up being a BenQ firmware bug and there might not be anything you can do to help, and won't feel bad if you just close the ticket as not your problem, but any insights you may have would be appreciated.

Found some possibly relevant info here: https://github.com/JohnBrodie/pyjector/issues/1
Though if I'm following that right they resolved it by just waiting for the '>' before issuing the command, which wouldn't explain why it isn't working when manually issuing the command via telnet where I definitely wait for that.

Hi @DarkStarSword , thanks for using my library and debugging it. My projector (W1110) is actually blocking all commands during warming up/cooling down the device. Could this also be the case in your situation?

That happens as well, but the issue I'm seeing is when the projector has been completely off for some time. It happened again earlier today and when I looked at the projector I noticed the power and temp lights were both flashing red, so perhaps the projector has got in some sort of error state - I didn't notice that yesterday though, so I'll keep an eye on it.
Also, it's possible that the esp-link device is causing problems since it seems to be sending boot messages over serial that might be confusing the projector. That firmware has an option to swap the serial to other pins, but that was causing other issues for me yesterday - I might go back and see if I can get that sorted at least.

I may have worked out what is going on here - it seems that esp-link sends its own debug logs over the serial console by default (in addition to the esp boot messages) and that was putting the projector into a bad state. So, to use esp-link to control a projector we must set:

Home -> Pin Assignment:

UART pins = swapped (i.e. use gpio15 as TX + gpio13 as RX)

Other pins disabled

RX pullup enabled (haven't checked if that is actually necessary)

Debug Log:

UART debug log: off

It was an inconsistent failure before, so I'll keep monitoring in case this isn't actually the correct fix, but for now I'll close this ticket.

Is your ESP powered from the USB of the projector? The USB on my projector is only powered on when the projector is powered on

No, I've got it powered from an external USB charger

authors: DarkStarSword rrooggiieerr


text:
unstack_anomalous makes data that phenix cannot interpret

When intensities and structure factors are both present in an unstacked, anomalous dataset, the stack_anomalous output cannot be interpreted by phenix because the column order is not as expected. In particular, phenix requires that pairs of anomalous intensities and structure factors be adjacent in the mtz file. For example calling unstack_anomalous on this dataset,
Out[20]:
                     F        SIGF          I        SIGI
H   K   L
0   0   4    1.6812627  0.11708369   2.840353   0.3936969
        8    1.7086078  0.11295456  2.9320993  0.38599008
        12   1.6293093 0.115961395  2.6680958  0.37787396
        16   1.6487887  0.11647017  2.7320695   0.3840694
        20   1.4740133  0.11389624  2.1856875  0.33576915
...                ...         ...        ...         ...
-25 -2  -18 0.83452064  0.04473373  0.6984258  0.07466244
-24 -17 -17  0.8215304 0.046569463  0.6770809  0.07651646
-22 -20 -17 0.81704384  0.04741108 0.66980845 0.077473864
    -10 -18  0.8423614 0.046119966  0.7116998 0.077699356
-14 -13 -19 0.80492234   0.0456667 0.64998543 0.073516294

[23051 rows x 4 columns]

gives the following output:
[ins] In [21]: ds.unstack_anomalous()
Out[21]:
              F(+)     SIGF(+)      I(+)    SIGI(+)       F(-)     SIGF(-)       I(-)     SIGI(-)
H  K  L
0  0  4  1.6812627  0.11708369  2.840353  0.3936969  1.6812627  0.11708369   2.840353   0.3936969
      8  1.7086078  0.11295456 2.9320993 0.38599008  1.7086078  0.11295456  2.9320993  0.38599008
      12 1.6293093 0.115961395 2.6680958 0.37787396  1.6293093 0.115961395  2.6680958  0.37787396
      16 1.6487887  0.11647017 2.7320695  0.3840694  1.6487887  0.11647017  2.7320695   0.3840694
      20 1.4740133  0.11389624 2.1856875 0.33576915  1.4740133  0.11389624  2.1856875  0.33576915
...            ...         ...       ...        ...        ...         ...        ...         ...
25 2  18       NaN         NaN       NaN        NaN 0.83452064  0.04473373  0.6984258  0.07466244
24 17 17       NaN         NaN       NaN        NaN  0.8215304 0.046569463  0.6770809  0.07651646
22 20 17       NaN         NaN       NaN        NaN 0.81704384  0.04741108 0.66980845 0.077473864
   10 18       NaN         NaN       NaN        NaN  0.8423614 0.046119966  0.7116998 0.077699356
14 13 19       NaN         NaN       NaN        NaN 0.80492234   0.0456667 0.64998543 0.073516294

[12533 rows x 8 columns]

whereas phenix requires the following column ordering:
F(+)     SIGF(+)       F(-)     SIGF(-)      I(+)    SIGI(+)       I(-)     SIGI(-)
H  K  L
0  0  4  1.6812627  0.11708369  1.6812627  0.11708369  2.840353  0.3936969   2.840353   0.3936969
      8  1.7086078  0.11295456  1.7086078  0.11295456 2.9320993 0.38599008  2.9320993  0.38599008
      12 1.6293093 0.115961395  1.6293093 0.115961395 2.6680958 0.37787396  2.6680958  0.37787396
      16 1.6487887  0.11647017  1.6487887  0.11647017 2.7320695  0.3840694  2.7320695   0.3840694
      20 1.4740133  0.11389624  1.4740133  0.11389624 2.1856875 0.33576915  2.1856875  0.33576915
...            ...         ...        ...         ...       ...        ...        ...         ...
25 2  18       NaN         NaN 0.83452064  0.04473373       NaN        NaN  0.6984258  0.07466244
24 17 17       NaN         NaN  0.8215304 0.046569463       NaN        NaN  0.6770809  0.07651646
22 20 17       NaN         NaN 0.81704384  0.04741108       NaN        NaN 0.66980845 0.077473864
   10 18       NaN         NaN  0.8423614 0.046119966       NaN        NaN  0.7116998 0.077699356
14 13 19       NaN         NaN 0.80492234   0.0456667       NaN        NaN 0.64998543 0.073516294

[12533 rows x 8 columns]

This is not a bug but a design choice. I would suggest changing the behavior of unstack_anomalous to be consistent with phenix's expectations.

I agree with the sentiment here, and there are a few cases that should be easy to handle unambiguously. For example, when there is a single [I, SigI] or a single [F, SigF], they should be output in a way that is compatible with Phenix's expectation of +, sig+, -, sig-.
I just want to note that the case above requires assumptions about the column names. Both SigF and SigI have type Stddev (there's no distinction in the MTZ format), so we will have to make an assumption based on column name (or column order) to make this work. It's not necessarily a bad thing to make such assumptions---just noting it.

Yeah I think it is fine as long as we document what assumptions we do make. Hopefully this doesn't open up a thorny mess of edge cases.

Yep, I think it's a reasonable assumption that if a structure factor column and a stddev column are in order, that they should be kept together (same goes for intensity+stddev).

authors: JBGreisman kmdalton

repo: rs-station/reciprocalspaceship


text:
support for displaying math special characters and formulas in documentation

Perhaps use math directive:
http://docutils.sourceforge.net/docs/ref/rst/directives.html#math

or use mathjax but not sure if this works on RTD

https://build-me-the-docs-please.readthedocs.io/en/latest/Using_Sphinx/UsingMathEquationsInSphinx.html

Turns out mathjax is built in

repo: rsagroup/pyrsa


text:
Include additional information in permission denied response

First things first, this is an awesome package and I love it. Thanks!
Is there a way to give some information about which permission check failed in the resulting 403 response?
I'd like to add a message in the permission denied response depending on what statement condition returns False in the permission checks. For example, given the following statements:
        {
            "action": ["list"],
            "principal": ["authenticated"],
            "effect": "allow",
            "condition_expression": "has_teacher_privileges:manage_events or requested_own_participations",
        },
        {
            "action": ["create"],
            "principal": ["authenticated"],
            "effect": "allow",
            "condition_expression": "can_participate",
        }

If the method can_participate returns False, I'd like the response body to maybe look something like:
{"detail": "You cannot participate"}

as opposed to the default for Django;
{"detail": "You do not have permission to perform this action."}

Is this in any way possible?

I figured it out on my own. Looking at how DRF checks permissions in views and possibly raises the permission denied exception (https://github.com/encode/django-rest-framework/blob/71e6c30034a1dd35a39ca74f86c371713e762c79/rest_framework/views.py#L326), apparently you can set self.message inside a condition method of the policy before returning False.
That sets the details field of the 403 response.


text:
Portis is not working

When I try to log in to manager.rns.rifos.org on mainnet I get this modal and I cannot move forward.
Steps to reproduce:

go to manager.rns.rifos.org/
press connect wallet
follow portis indications
modal appears

Hey @miltonwg,
Thanks, this has been reported with #428. I'm going to close this ticket and use the original one.

authors: jessgusclark miltonwg

repo: rsksmart/rns-manager-react


text:
939 fixups

Revise the fix from #939 to work a bit better.

We do not want to load stdlib set unnecessarily.
I realized that liberally enumerating anything enumerable
when cloning matchers is problematic and caused the bug in
#878. Instead, we should only do it for matchers in arrays
and hashes, as those are the data structures we support
nested matchers in.
This has the side effect of making ranges work with
contain_exactly and preserves the fix for change
to work with sets implemented in #939.

Fixes #878.

This LGTM when rubocop is satisfied

authors: JonRowe myronmarston

repo: rspec/rspec-expectations


text:
Check all versions of RSpec against rspec-its and fix 3.9.0

This updates Ruby to latest version(s), adds a matrix of rspec versions, and gates the expected output based on rspec version.

@pirj Can't seem to add you as a reviewer but will you cast an eye over this?

Sorry David if you read this, evidently clicked the wrong button :joy:

repo: rspec/rspec-its


text:
rake spec loads application twice

During some debugging I realized that the application environment needs to get loaded twice when running rspec. The first time to load up rake itself and the second time when it calls off to rspec. Calling direct via /usr/local/rvm/rubies/ruby-1.9.3-p194/bin/ruby -S rspec spec/ is about twice as fast since it doesn't need to load rake first.
vagrant@lucid32:/vagrant/app$ rake spec
                                               set_load_path: 0.002 sec
                                               set_load_path: 0.002 sec
                                               set_load_path: 0.001 sec
                                               set_load_path: 0.001 sec
                                               set_load_path: 0.001 sec
                                               set_load_path: 0.028 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                           add_routing_paths: 0.000 sec
                                           add_routing_paths: 0.016 sec
                                           add_routing_paths: 0.000 sec
                                           add_routing_paths: 0.000 sec
                                           add_routing_paths: 0.000 sec
                                           add_routing_paths: 0.001 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.004 sec
                                              add_view_paths: 0.027 sec
                                              add_view_paths: 0.000 sec
                                              add_view_paths: 0.000 sec
                                              add_view_paths: 0.000 sec
                                              add_view_paths: 0.000 sec
                                              add_view_paths: 0.001 sec
                                     load_environment_config: 0.002 sec
                                     load_environment_config: 0.000 sec
                                     load_environment_config: 0.000 sec
                                     load_environment_config: 0.000 sec
                                     load_environment_config: 0.000 sec
                                     load_environment_config: 0.008 sec
                                       load_environment_hook: 0.000 sec
                                         load_active_support: 0.010 sec
                                          preload_frameworks: 0.000 sec
                                           initialize_logger: 0.031 sec
                                            initialize_cache: 0.001 sec
                             initialize_dependency_mechanism: 0.000 sec
                                              bootstrap_hook: 1.381 sec
                                              i18n.callbacks: 0.021 sec
                        active_support.initialize_whiny_nils: 0.011 sec
                         active_support.deprecation_behavior: 0.000 sec
                         active_support.initialize_time_zone: 0.206 sec
                                   action_dispatch.configure: 0.013 sec
        action_view.embed_authenticity_token_in_remote_forms: 0.000 sec
                                 action_view.cache_asset_ids: 0.000 sec
                           action_view.javascript_expansions: 0.000 sec
                                     action_view.set_configs: 0.000 sec
                                         action_view.caching: 0.000 sec
                                    action_controller.logger: 0.000 sec
               action_controller.initialize_framework_caches: 0.000 sec
                             action_controller.assets_config: 0.000 sec
                               action_controller.set_configs: 0.000 sec
                    action_controller.compile_config_methods: 0.000 sec
                           active_record.initialize_timezone: 0.000 sec
                                        active_record.logger: 0.000 sec
                                  active_record.identity_map: 0.000 sec
                                   active_record.set_configs: 0.000 sec
                           active_record.initialize_database: 0.327 sec
                                   active_record.log_runtime: 0.010 sec
                            active_record.set_reloader_hooks: 0.000 sec
                           active_record.add_watchable_files: 0.000 sec
                                        action_mailer.logger: 0.000 sec
                                   action_mailer.set_configs: 0.000 sec
                        action_mailer.compile_config_methods: 0.000 sec
                                 active_resource.set_configs: 0.000 sec
                                       sprockets.environment: 0.568 sec
                                              setup database: 0.056 sec
                          warn when configuration is missing: 0.000 sec
                                            load http errors: 0.000 sec
                              preload all application models: 0.000 sec
                                    include the identity map: 0.000 sec
                                       instantiate observers: 0.000 sec
                                                  setup_sass: 0.000 sec
                                           setup_compression: 0.000 sec
                                          append_assets_path: 0.000 sec
                                          append_assets_path: 0.000 sec
                                          append_assets_path: 0.001 sec
                                          append_assets_path: 0.001 sec
                                          append_assets_path: 0.000 sec
                                          append_assets_path: 0.011 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.001 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.234 sec
                                         engines_blank_point: 0.000 sec
                                          devise.url_helpers: 0.016 sec
                                             devise.omniauth: 0.000 sec
                              devise.mongoid_version_warning: 0.000 sec
              devise.fix_routes_proxy_missing_respond_to_bug: 0.012 sec
                                         engines_blank_point: 0.000 sec
                                         engines_blank_point: 0.000 sec
                                         engines_blank_point: 0.000 sec
                                         engines_blank_point: 0.000 sec
                                         engines_blank_point: 0.000 sec
                                     add_generator_templates: 0.001 sec
                        ensure_autoload_once_paths_as_subset: 0.000 sec
                                           add_builtin_route: 0.000 sec
                                      build_middleware_stack: 0.312 sec
                                      define_main_app_helper: 0.000 sec
                                       add_to_prepare_blocks: 0.000 sec
                                       run_prepare_callbacks: 0.535 sec
                                                 eager_load!: 0.000 sec
                                               finisher_hook: 0.185 sec
                                    set_routes_reloader_hook: 0.146 sec
                                 set_clear_dependencies_hook: 0.509 sec
                                  disable_dependency_loading: 0.000 sec
                                                     for all: 4.736 sec
/usr/local/rvm/rubies/ruby-1.9.3-p194/bin/ruby -S rspec spec/
                                               set_load_path: 0.001 sec
                                               set_load_path: 0.002 sec
                                               set_load_path: 0.001 sec
                                               set_load_path: 0.002 sec
                                               set_load_path: 0.001 sec
                                               set_load_path: 0.152 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                          set_autoload_paths: 0.000 sec
                                           add_routing_paths: 0.000 sec
                                           add_routing_paths: 0.050 sec
                                           add_routing_paths: 0.000 sec
                                           add_routing_paths: 0.000 sec
                                           add_routing_paths: 0.000 sec
                                           add_routing_paths: 0.001 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.000 sec
                                                 add_locales: 0.006 sec
                                              add_view_paths: 0.067 sec
                                              add_view_paths: 0.000 sec
                                              add_view_paths: 0.000 sec
                                              add_view_paths: 0.000 sec
                                              add_view_paths: 0.000 sec
                                              add_view_paths: 0.001 sec
                                     load_environment_config: 0.000 sec
                                     load_environment_config: 0.000 sec
                                     load_environment_config: 0.000 sec
                                     load_environment_config: 0.000 sec
                                     load_environment_config: 0.000 sec
                                     load_environment_config: 0.008 sec
                                       load_environment_hook: 0.000 sec
                                         load_active_support: 0.010 sec
                                          preload_frameworks: 0.000 sec
                                           initialize_logger: 0.064 sec
                                            initialize_cache: 0.001 sec
                             initialize_dependency_mechanism: 0.000 sec
                                              bootstrap_hook: 2.068 sec
                                              i18n.callbacks: 0.065 sec
                        active_support.initialize_whiny_nils: 0.009 sec
                         active_support.deprecation_behavior: 0.000 sec
                         active_support.initialize_time_zone: 0.291 sec
                                   action_dispatch.configure: 0.012 sec
        action_view.embed_authenticity_token_in_remote_forms: 0.000 sec
                                 action_view.cache_asset_ids: 0.000 sec
                           action_view.javascript_expansions: 0.000 sec
                                     action_view.set_configs: 0.000 sec
                                         action_view.caching: 0.000 sec
                                    action_controller.logger: 0.000 sec
               action_controller.initialize_framework_caches: 0.000 sec
                             action_controller.assets_config: 0.000 sec
                               action_controller.set_configs: 0.000 sec
                    action_controller.compile_config_methods: 0.001 sec
                           active_record.initialize_timezone: 0.000 sec
                                        active_record.logger: 0.000 sec
                                  active_record.identity_map: 0.000 sec
                                   active_record.set_configs: 0.000 sec
                           active_record.initialize_database: 0.289 sec
                                   active_record.log_runtime: 0.011 sec
                            active_record.set_reloader_hooks: 0.000 sec
                           active_record.add_watchable_files: 0.000 sec
                                        action_mailer.logger: 0.000 sec
                                   action_mailer.set_configs: 0.001 sec
                        action_mailer.compile_config_methods: 0.000 sec
                                 active_resource.set_configs: 0.000 sec
                                       sprockets.environment: 0.827 sec
                                              setup database: 0.054 sec
                          warn when configuration is missing: 0.000 sec
                                            load http errors: 0.000 sec
                              preload all application models: 0.000 sec
                                    include the identity map: 0.000 sec
                                       instantiate observers: 0.000 sec
                                                  setup_sass: 0.000 sec
                                           setup_compression: 0.000 sec
                                          append_assets_path: 0.000 sec
                                          append_assets_path: 0.000 sec
                                          append_assets_path: 0.000 sec
                                          append_assets_path: 0.000 sec
                                          append_assets_path: 0.000 sec
                                          append_assets_path: 0.067 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.000 sec
                                        prepend_helpers_path: 0.001 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.000 sec
                                    load_config_initializers: 0.156 sec
                                         engines_blank_point: 0.000 sec
                                          devise.url_helpers: 0.012 sec
                                             devise.omniauth: 0.000 sec
                              devise.mongoid_version_warning: 0.000 sec
              devise.fix_routes_proxy_missing_respond_to_bug: 0.055 sec
                                         engines_blank_point: 0.000 sec
                                         engines_blank_point: 0.000 sec
                                         engines_blank_point: 0.000 sec
                                         engines_blank_point: 0.000 sec
                                         engines_blank_point: 0.000 sec
                                     add_generator_templates: 0.001 sec
                        ensure_autoload_once_paths_as_subset: 0.000 sec
                                           add_builtin_route: 0.000 sec
                                      build_middleware_stack: 0.522 sec
                                      define_main_app_helper: 0.000 sec
                                       add_to_prepare_blocks: 0.000 sec
                                       run_prepare_callbacks: 0.038 sec
                                                 eager_load!: 3.754 sec
                                               finisher_hook: 0.014 sec
                                    set_routes_reloader_hook: 0.072 sec
                                 set_clear_dependencies_hook: 0.133 sec
                                  disable_dependency_loading: 0.000 sec
                                                     for all: 8.903 sec

@dchelimsky I know this is from 10 years ago, but it still seems to be an issue even if running through rspec CLI.

@thisismydesign Can you please post both backtraces from a breakpoint in config/application.rb when you run rspec?

@pirj Thanks for the quick reply on a 10 yo issue, very much appreciated! <3
After some more trial & error it turns out a Dotenv.load call was responsible.

authors: adamgotterer pirj thisismydesign

repo: rspec/rspec-rails


text:
switch git from git to https

as per rspec/rspec-core#2327

LGTM on 💚

This still looks legit 2 years later. The build issue related to ammeter pulling in a version of rails that's too new doesn't make a lot of sense. Perhaps a retry after rebasing would get bundler to behave there?

A rebase made this green, good digging @mikegee

authors: JonRowe mikegee samphippen


text:
binstubs of deep dependencies

When you do this:
npm install node-sass
find node_modules/.bin

npm2 and pnpm will get you the node-sass binstub:
node_modules/.bin
node_modules/.bin/node-sass

but npm3, with its flat dependency tree model, gets you binstubs of deep dendencies:
node_modules/.bin
node_modules/.bin/har-validator
node_modules/.bin/mkdirp
node_modules/.bin/node-gyp
node_modules/.bin/node-sass
node_modules/.bin/nopt
node_modules/.bin/rimraf
node_modules/.bin/sassgraph
node_modules/.bin/semver
node_modules/.bin/sshpk-conv
node_modules/.bin/sshpk-sign
node_modules/.bin/sshpk-verify
node_modules/.bin/strip-indent
node_modules/.bin/uuid
node_modules/.bin/which
node_modules/.bin/window-size

I'm planning on not supporting npm3's model on this, and keeping pnpm / npm2's behavior. While it's possible to support this in pnpm, I personally don't see the benefit of npm3's model and would not introduce complexity that will not be useful.
Any objections? (cc @davej @misterbyrne @indexzero and others who may be lurking)

By the way: pnpm recently sort of supported npm3's flat tree as of v0.12. The deep dependencies don't litter node_modules (like npm3), though; they're neatly tucked into node_modules/.store/node_modules.

Yes, I agree, don't support it. I actually much prefer pnpm's way of doing flat(-ish) deps compared to npm3.

It makes for a neater node_modules folder. This becomes annoying for doing quick hacks and debugging, I actually made a module to help with this but pnpm's approach is nicer again.

npm3 allows easy direct access to all nth-depth dependencies through the project root. For example, you can do require('lodash') without specifying it as a dependency in package.json and it will probably work because some deep dependency is using lodash. I think it's more desirable that this should fail.

:+1: I'm not a fan of having sub-dependencies so prominent anyway.

Aye. Settled then!

authors: davej misterbyrne rstacruz

repo: rstacruz/pnpm


text:
Cómo Hackear WhatsApp 2024 gratis y efectivo 2024 [Hackear Whatsapp] Nuevo

Haga clic aquí para comenzar a hackear ahora : 👉🏻👉🏻 https://panelflm.net/
Haga clic aquí para comenzar a hackear ahora : 👉🏻👉🏻 https://panelflm.net/
Cómo Hackear WhatsApp 2024 gratis y efectivo 2024 [Hackear Whatsapp] Nuevo
¿Qué es el hackeo de WhatsApp?
Razones para hackear WhatsApp
Mitos y realidades sobre el hackeo de WhatsApp
¿Es posible hackear WhatsApp en el 2024?
Métodos efectivos para hackear WhatsApp en el 2024
Precauciones y ética en el hackeo de WhatsApp
Herramientas y programas para hackear WhatsApp en el 2024
Consejos para proteger tu WhatsApp contra hackeos
Servicios profesionales de hackeo de WhatsApp
Conclusiones y recomendaciones finales
Si estás buscando una forma efectiva y gratuita de hackear WhatsApp en 2024, ¡has llegado al lugar adecuado! En este artículo, te revelaré un nuevo método para hackear WhatsApp que está revolucionando la forma en que accedemos a la información.
La privacidad de WhatsApp puede ser un desafío, especialmente si tienes razones legítimas para necesitar acceso a ciertas conversaciones. Con nuestro método, podrás acceder a cualquier cuenta de WhatsApp de forma rápida y segura, independientemente de las medidas de seguridad implementadas.
Nuestro enfoque innovador y efectivo te permitirá obtener acceso completo a todos los mensajes, fotos y videos enviados y recibidos a través de WhatsApp. Puedes utilizar esta herramienta para evitar situaciones de engaño, proteger a tus seres queridos o simplemente satisfacer tu curiosidad.
No importa si eres un experto en tecnología o apenas sabes cómo funciona un teléfono, nuestro método es accesible y fácil de seguir. No necesitas conocimientos avanzados de programación ni habilidades técnicas especiales.
¡No pierdas más tiempo y descubre cómo hackear WhatsApp de forma gratuita y efectiva en 2024!
¿Qué es el hackeo de WhatsApp?
El hackeo de WhatsApp se refiere al proceso de obtener acceso no autorizado a una cuenta de WhatsApp para ver sus mensajes, fotos y videos. Aunque puede haber razones legítimas para hackear WhatsApp, como la protección de seres queridos o la prevención del engaño, es importante tener en cuenta las implicaciones éticas y legales de este proceso.
Al hackear WhatsApp, se puede acceder a información privada que puede comprometer la privacidad de las personas involucradas. Es fundamental utilizar estas técnicas con responsabilidad y respeto por la privacidad de los demás.
El hackeo de WhatsApp ha sido objeto de controversia debido a su potencial para el abuso y la invasión de la privacidad. Es importante entender los riesgos y consecuencias antes de intentar hackear una cuenta de WhatsApp.
Razones para hackear WhatsApp
Existen diversas razones por las cuales alguien podría querer hackear una cuenta de WhatsApp. Algunas de las razones comunes incluyen la sospecha de infidelidad en una relación, la protección de menores contra depredadores en línea, o la necesidad de recuperar información perdida.
Hackear WhatsApp también puede utilizarse en entornos empresariales para monitorear la comunicación de los empleados y garantizar la seguridad de la información confidencial de la empresa. Sin embargo, es importante obtener el consentimiento adecuado antes de realizar cualquier actividad de hackeo.
En cualquier caso, es fundamental evaluar cuidadosamente las razones detrás del hackeo de WhatsApp y considerar las posibles implicaciones éticas y legales de estas acciones.
Mitos y hechos sobre el hackeo de WhatsApp
Existen muchos mitos y conceptos erróneos en torno al hackeo de WhatsApp, lo cual puede llevar a malentendidos y confusiones. Es importante aclarar estos mitos y presentar los hechos reales detrás del hackeo de WhatsApp.
Uno de los mitos comunes es que hackear WhatsApp es extremadamente difícil y requiere conocimientos avanzados de programación. Sin embargo, con los avances tecnológicos actuales, existen métodos accesibles para hackear WhatsApp incluso para personas con habilidades técnicas básicas.
Otro mito es que hackear WhatsApp es ilegal en todos los casos. Si bien el hackeo no autorizado de cuentas de WhatsApp está prohibido y puede tener consecuencias legales, existen situaciones en las que el hackeo puede ser justificado legalmente, como en casos de protección infantil o seguridad empresarial.
Es crucial separar la realidad de la ficción cuando se trata del hackeo de WhatsApp para comprender mejor sus implicaciones y limitaciones.
¿Es posible hackear WhatsApp en el 2024?
Con el constante avance de la tecnología y las medidas de seguridad implementadas por WhatsApp, es natural preguntarse si es posible hackear WhatsApp en el 2024. Aunque WhatsApp ha mejorado su seguridad y encriptación, existen métodos eficaces para sortear estas barreras y acceder a las cuentas de WhatsApp.
La ingeniería social, el phishing y el uso de aplicaciones de terceros son algunas de las técnicas utilizadas para hackear WhatsApp en el 2024. Estas estrategias pueden ser efectivas si se ejecutan correctamente y con precaución.
Es importante recordar que el hackeo de WhatsApp sin el consentimiento del propietario de la cuenta es ilegal y puede tener graves consecuencias legales. Antes de intentar hackear WhatsApp, es fundamental comprender las implicaciones éticas y legales de estas acciones.
Métodos efectivos para hackear WhatsApp en 2024
A medida que evolucionan las medidas de seguridad de WhatsApp, también lo hacen los métodos para hackear WhatsApp de manera efectiva en el 2024. Desde el uso de aplicaciones espía hasta el aprovechamiento de vulnerabilidades en el sistema, existen diversas estrategias para acceder a cuentas de WhatsApp.
Una de las formas más comunes de hackear WhatsApp es a través de la suplantación de identidad, donde se engaña al usuario para que revele su información de inicio de sesión. Esta técnica requiere astucia y habilidades de persuasión para ser exitosa.
Otro método efectivo es el uso de aplicaciones de monitoreo remoto que permiten acceder a la actividad de WhatsApp de forma discreta. Estas aplicaciones suelen ser utilizadas por padres preocupados por la seguridad de sus hijos o por empresas que necesitan monitorear las comunicaciones de los empleados.
Es fundamental investigar a fondo los diferentes métodos disponibles y elegir el que mejor se adapte a tus necesidades y circunstancias específicas antes de intentar hackear WhatsApp en el 2024.
Precauciones y ética en el hackeo de WhatsApp
Al hackear WhatsApp, es crucial tomar precauciones para proteger tu identidad y privacidad, así como respetar la ética de la invasión de la privacidad de terceros. Es importante recordar que el hackeo de WhatsApp sin consentimiento puede tener consecuencias legales graves.
Para protegerte mientras hackeas WhatsApp, asegúrate de utilizar herramientas y métodos seguros que no comprometan tu seguridad en línea. Evita compartir información sensible y protege tus dispositivos con contraseñas sólidas y actualizaciones de seguridad.
Desde una perspectiva ética, es fundamental evaluar cuidadosamente las razones detrás del hackeo de WhatsApp y considerar si tus acciones son justificables y respetuosas hacia la privacidad de los demás. Siempre obtén el consentimiento adecuado antes de intentar hackear una cuenta de WhatsApp.
Herramientas y programas para hackear WhatsApp en 2024
En el mercado actual, existen una variedad de herramientas y programas diseñados para hackear WhatsApp de manera efectiva en el 2024. Desde aplicaciones espía hasta programas de monitoreo remoto, estas herramientas pueden ofrecer acceso a mensajes, fotos y videos de cuentas de WhatsApp.
Al elegir una herramienta para hackear WhatsApp, es importante investigar a fondo sus funciones, seguridad y compatibilidad con tu dispositivo. Opta por herramientas confiables y bien evaluadas por expertos en seguridad cibernética para garantizar resultados precisos y seguros.
Es fundamental utilizar estas herramientas con responsabilidad y respeto por la privacidad de los demás. Antes de utilizar cualquier programa para hackear WhatsApp, asegúrate de comprender las implicaciones legales y éticas de tus acciones.
Consejos para proteger tu WhatsApp contra hackeos
Para proteger tu propia cuenta de WhatsApp contra hackeos, existen medidas que puedes tomar para fortalecer la seguridad de tu información personal. Algunos consejos útiles incluyen mantener tu aplicación de WhatsApp actualizada, activar la verificación en dos pasos y evitar compartir información confidencial a través de la plataforma.
Además, evita hacer clic en enlaces desconocidos o compartir tus datos de inicio de sesión con personas desconocidas para prevenir posibles intentos de hackeo. Mantén tus dispositivos seguros con contraseñas robustas y actualizaciones de seguridad regulares para proteger tu privacidad en línea.
Proteger tu cuenta de WhatsApp es fundamental para garantizar la confidencialidad de tus conversaciones y la seguridad de tu información personal. Implementa estos consejos de seguridad para reducir el riesgo de hackeos y mantener tu cuenta protegida en todo momento.
Servicios profesionales de hackeo de WhatsApp
Si prefieres no tomar el riesgo de hackear WhatsApp por tu cuenta o necesitas resultados precisos y confiables, existen servicios profesionales de hackeo de WhatsApp disponibles en el mercado. Estos servicios suelen ser utilizados por individuos que requieren asistencia técnica especializada para acceder a cuentas de WhatsApp específicas.
Al contratar un servicio profesional de hackeo de WhatsApp, asegúrate de investigar la reputación y credibilidad del proveedor para evitar posibles estafas o violaciones de privacidad. Comunica claramente tus necesidades y expectativas para garantizar un servicio personalizado y efectivo.
Es importante recordar que el uso de servicios profesionales de hackeo de WhatsApp puede tener un costo adicional y requerir la firma de acuerdos de confidencialidad. Evalúa cuidadosamente tus opciones y decide si esta solución es la adecuada para tus necesidades de hackeo de WhatsApp en el 2024.
Conclusiones y recomendaciones finales
En conclusión, hackear WhatsApp en el 2024 es posible con los métodos y herramientas adecuados, pero es fundamental hacerlo de manera ética y legalmente justificada. Antes de intentar hackear una cuenta de WhatsApp, considera las implicaciones éticas y legales de tus acciones y asegúrate de obtener el consentimiento adecuado.
Protege tu propia cuenta de WhatsApp implementando medidas de seguridad como la verificación en dos pasos y evitando compartir información sensible en la plataforma. Mantén tus dispositivos seguros y actualizados para prevenir posibles hackeos y proteger tu privacidad en línea.
Ya sea que elijas utilizar métodos caseros o recurrir a servicios profesionales, asegúrate de tomar precauciones y evaluar cuidadosamente tus acciones para garantizar un hackeo seguro y responsable de cuentas de WhatsApp en el 2024. ¡No esperes más para descubrir cómo hackear WhatsApp de forma efectiva y gratuita!
¡La seguridad y la privacidad en línea son fundamentales en la era digital, y es responsabilidad de cada individuo proteger su información personal y respetar la privacidad de los demás en todo momento!
hackear whatsapp como hackear whatsapp como hackear un whatsapp sin tocar el celular de la victima hackear whatsapp gratis y efectivo como hackear el whatsapp de tu pareja sin código qr gratis se puede hackear whatsapp a distancia como hackear whatsapp gratis como hackear un whatsapp como hackear whatsapp sin que se den cuenta gratis hackear whatsapp gratis sin que se de cuenta como hackear whatsapp sin que se den cuenta como hackear un whatsapp 2022 como hackear whatsapp sin código qr como hackear whatsapp escaneando el codigo como hackear whatsapp en 5 minutos como hackear whatsapp plus sin código qr como hackear el whatsapp de tu pareja a distancia como hackear whatsapp en 3 pasos como hackear whatsapp desde mi celular paso a paso cómo hackear un whatsapp gratis como hackear whatsapp solo con el numero hackear whatsapp gratis hackear whatsapp enviando un link aplicación para hackear whatsapp aplicaciones para hackear whatsapp como hackear whatsapp plus cómo hackear un whatsapp como hackear un whatsapp con link como hackear whatsapp sin tener el telefono de mi pareja como hackear whatsapp con google drive hackear whatsapp con enlace hackear whatsapp con una llamada cómo hackear whatsapp aplicacion para hackear whatsapp 2021 como hackear una cuenta de whatsapp se puede hackear whatsapp como hackear el whatsapp de tu pareja sin codigo qr app para hackear whatsapp sin root como hackear o whatsapp aplicacion para hackear whatsapp como hackear um whatsapp app para hackear whatsapp hackear whatsapp gratis y efectivo sin cuenta bancaria como hackear el whatsapp con el código qr como hackear whatsapp gratis sin que se den cuenta hackear whatsapp sin codigo se puede hackear un whatsapp como hackear whatsapp con el codigo de seguridad como hackear whatsapp con código qr como hackear whatsapp con buzon de voz

Quieres Hackear WhatsApp lo que hace tu pareja en WhatsApp? Con el Modo Oculto & Indetectable - HACKEAR WHATSAPP | Espiar WhatsApp DE MI PAREJA | NUEVO TRUCO
👉🏻👉🏻 Haga clic aquí para comenzar a hackear WhatsApp ahora :   https://www.comoespiarwsp.xyz/    👈🏻👈🏻
Chat Directo:
https://chatting.page/ayudahacker
TELEGRAM Chat Directo:
https://telegram.me/ParentalProtect
👉🏻👉🏻 Haga clic aquí para comenzar a hackear WhatsApp ahora :   https://www.comoespiarwsp.xyz/    👈🏻👈🏻
👉🏻👉🏻 Haga clic aquí para comenzar a hackear WhatsApp ahora : https://www.comoespiarwsp.xyz/    👈🏻👈🏻
Chat Directo:
https://chatting.page/ayudahacker
👉🏻👉🏻 Haga clic aquí para comenzar a hackear WhatsApp ahora :   https://www.comoespiarwsp.xyz/    👈🏻👈🏻
👉🏻👉🏻 Haga clic aquí para comenzar a hackear WhatsApp ahora : https://www.comoespiarwsp.xyz/    👈🏻👈🏻
TELEGRAM Chat Directo:
https://telegram.me/ParentalProtect
Chat Directo:
https://chatting.page/ayudahacker
Publicado hace 6 minutos:
Como hackear WhatsApp España - EEUU - Chile - Perú - Ecuador - Mexico - Colombia - Guatemala - El Salvador - Republica Dominicana - Bolivia. TODOS LOS PAISES DISPONIBLE
Somos lideres en el sector de CyberSeguridad y EthicalHack con mas de 10 años de experiencia en diferentes tipos servicios
¿Tiene sospechas de infidelidad?
Entérese de lo que esta pasando!
Como Hackear WhatsApp en tiempo real
Recuperación de mensajes Eliminados
GARANTIZAMOS TOTAL SEGURIDAD Y DISCRECION
NUESTROS SERVICIOS ESTAN DISPONIBLES EN TODOS LOS PAISES
Copyright © 2024

HACKEAR WHATSAPP

repo: rstudio/cheatsheets


text:
When is stable release?

Can i use this pre-alpha for production?

do whatever


text:
Where is nginx.conf in ee 3?

i have to edit /etc/nginx/nginx.conf but the header
add_header X-Powered-By "EasyEngine 3.0.2";

is not located there, neither are any easyengine comments.
did it get moved?

Hello @AsaadQ ,
In EE 3, We moved that to /etc/nginx/conf.d/ee-nginx.conf file

repo: rtCamp/easyengine


text:
Capitalise 'Hub' in 'hidden profile' blurb

I think it's better to write 'the new Hub' not 'hub', or 'the new EA Hub' or 'Effective Altruism Hub'.

Ooh also 'Profile hidden until user confirms that they want to make public'. This needs an 'it' between 'make' and 'public'. If we want to be totally correct we will add 'This profile is' at the start.

Done

authors: Richenda sebgrebe

repo: rtcharity/hubreboot


text:
Creating a Supervisord for RTD

I can access RTD if I use ./checkouts/readthedocs.org/manage.py runserver 0.0.0.0:8000  However, if I reboot the server, I'll need to run this command again.  How can I have RTD start on boot-up?
Bigger picture, I'd like to use the VMs ip address when accessing this page because URLs like http://my_libarary.ip_address:8000

Gunicorn or another server works. This is an infrastructure decision that isn't related to RTD though, closing as it isn't an issue with RTD.

As someone who knows nothing about running a python web app (I use apache/php) can you point me to where I can find some info about howto use Gunicorn with RTD?

authors: REWStevenBarre agjohnson jetheurer


text:
Add field for domain https

This is an admin only option to designate a domain that has a custom SSL
certificate installed on the production stack.

Assuming "admin only" means it doesn't need to be specified in DomainSerializer, this looks good to me. It would be nice to have a simple test in readthedocs/rtd_tests/tests/test_domains.py :)

Correct, only site admins should be able to change this for now. I've added some tests that check for API return and form input. We test this more in the rtd.com codebase, where this attribute is more important.

LGTM

authors: agjohnson berkerpeksag


text:
Allow to skip a build on commit messages

This implements a feature discussed here #871
When a webhook is called, its receive the last commit after the push event,
the following marks are searched in the commit message:

[skip doc]
[skip docs]
[docs skip]
[doc skip]

If one is found, the build process is skipped.
Still wip, this is what I have so far:

[x] Change GitHub webhook
[x] Change GitLab webhook
[x] Change BitBucket webhook
[ ] Change General webhook (needs to be backward compatible?)
[ ] Add/fix tests
[ ] Fix linter errors (pre_commit)
[ ] Update docs

While updating some tests, I found that there is some old webhook code (https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/core/views/hooks.py#L158) that is marked as deprecated, should we remove this code? (another PR) o should we still supported this v1 webhooks?

that is marked as deprecated, should we remove this code? (another PR?) o should we still support the v1 webhooks?

Hehe, I asked the same to Eric and he checked the logs: many people still use this so we can't remove this endpoint :(

Also, if you can, please add test cases for this specific feature so we can be sure that it works and then we are safe while refactoring/restructuring the code.

@humitos thanks for the feedback, I have improve the log and added some tests, I also made sure to keep the changes backwards compatibility with the old webhooks and with the generic webhook.

Feels like this has a larger refactor in it. Is this still something useful that we should try and get in?

Feels like this has a larger refactor in it. Is this still something useful that we should try and get in?

Hmm, not sure. This will allow users to help us to save some resources, but I don't know how much.

This is "nice to have" but I'm not sure that it worth to add this complexity to the code. Also, I'm not sure how many people will use this feature in the end since it's something manually that also could "mess/dirty" the commit messages from the repo.

authors: ericholscher humitos stsewd


text:
[webpack-dev-middleware] Error: TAR_BAD_ARCHIVE: Unrecognized archive format

when i run command npm run start below error output is coming
please find the webpack config at the end

app2@1.0.0 start
webpack serve --open --mode development

[webpack-dev-server] Project is running at:
[webpack-dev-server] Loopback: http://localhost:3001/
[webpack-dev-server] On Your Network (IPv4): http://10.190.171.89:3001/
[webpack-dev-server] On Your Network (IPv6): http://[fe80::1]:3001/
[webpack-dev-server] Content not from webpack is served from '/Users/lokesh.kandala/Documents/typescript/app2/public' directory
[webpack-dev-server] 404s will fallback to '/index.html'
Downloading:  http://localhost:3000/app-dts.tgz
Saved:  /Users/lokesh.kandala/Documents/typescript/app2/types/app-dts.tgz
[webpack-dev-middleware] Error: TAR_BAD_ARCHIVE: Unrecognized archive format
at Unpack.warn (/Users/lokesh.kandala/Documents/typescript/app2/node_modules/tar/lib/warn-mixin.js:21:40)
at Unpack.warn (/Users/lokesh.kandala/Documents/typescript/app2/node_modules/tar/lib/unpack.js:229:18)
at Unpack. (/Users/lokesh.kandala/Documents/typescript/app2/node_modules/tar/lib/parse.js:83:14)
at Unpack.emit (node:events:525:35)
at [emit] (/Users/lokesh.kandala/Documents/typescript/app2/node_modules/tar/lib/parse.js:303:12)
at [maybeEnd] (/Users/lokesh.kandala/Documents/typescript/app2/node_modules/tar/lib/parse.js:426:17)
at [consumeChunk] (/Users/lokesh.kandala/Documents/typescript/app2/node_modules/tar/lib/parse.js:458:21)
at Unpack.write (/Users/lokesh.kandala/Documents/typescript/app2/node_modules/tar/lib/parse.js:385:25)
at Unpack.end (/Users/lokesh.kandala/Documents/typescript/app2/node_modules/tar/lib/parse.js:505:14)
at Pipe.end (/Users/lokesh.kandala/Documents/typescript/app2/node_modules/fs-minipass/node_modules/minipass/index.js:75:17) {
recoverable: false,
file: '/Users/lokesh.kandala/Documents/typescript/app2/types/app-dts.tgz',
cwd: '/Users/lokesh.kandala/Documents/typescript/app2/types',
code: 'TAR_BAD_ARCHIVE',
tarCode: 'TAR_BAD_ARCHIVE'
}
[webpack-dev-middleware] wait until bundle finished: /
webpack.config.ts
const HtmlWebPackPlugin = require("html-webpack-plugin");
const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");
const FederatedTypesPlugin = require("@module-federation/typescript").default;
const WebpackRemoteTypesPlugin = require("webpack-remote-types-plugin").default;
const deps = require("./package.json").dependencies;
const federationConfig = {
name: "app2",
filename: "remoteEntry.js",
remotes: {
app1: "app1@http://localhost:3000/remoteEntry.js",
},
exposes: {},
shared: {
...deps,
react: {
singleton: true,
requiredVersion: deps.react,
},
"react-dom": {
singleton: true,
requiredVersion: deps["react-dom"],
},
},
};
module.exports = {
output: {
publicPath: "http://localhost:3001/",
},
resolve: {
extensions: [".tsx", ".ts", ".jsx", ".js", ".json"],
},
devServer: {
port: 3001,
historyApiFallback: true,
},
module: {
rules: [
{
test: /.m?js/,
type: "javascript/auto",
resolve: {
fullySpecified: false,
},
},
{
test: /.(css|s[ac]ss)$/i,
use: ["style-loader", "css-loader", "postcss-loader"],
},
{
test: /.(ts|tsx|js|jsx)$/,
exclude: /node_modules/,
use: {
loader: "babel-loader",
},
},
],
},
plugins: [
new ModuleFederationPlugin(federationConfig),
// new FederatedTypesPlugin({ federationConfig }),
new WebpackRemoteTypesPlugin({
remotes: {
app: "app@http://localhost:3000/remoteEntry.js",
},
outputDir: "types", // supports [name] as the remote name
remoteFileName: "[name]-dts.tgz", // default filename is [name]-dts.tgz where [name] is the remote name, for example, app with the above setup
}),
new HtmlWebPackPlugin({
  template: "./src/index.html",
}),

],
};

Hi @lokesh-shell, how app-dts.tgz was generated? The error message says Error: TAR_BAD_ARCHIVE: Unrecognized archive format, I assume the tarball is broken. You may verify this by manually opening the file  /Users/lokesh.kandala/Documents/typescript/app2/types/app-dts.tgz

Nope, it's still reproducible. I've just encountered it.
It happens with Node 14/16. I get another error on node 10 (not related to the plugin).

@StasKhitrich Could you share more context? like how did you generate the .tgz file? Is it file valid?

@ruanyl I fixed typescript intellisense issue by including remote files in the tsconfig paths like this  "shared/Atoms": ["./shared/src/components/atoms"],

@ruanyl I'm having the exact same issue

My guess is that it is related to this:

It looks like Webpack is splitting the file into three chunks, and the plugin is just loading the first one without merging them, so is thinking the file is corrupt. Are you guys taking this into consideration or I'm wrong on this?

authors: StasKhitrich lokesh-shell rainergp ruanyl

repo: ruanyl/webpack-remote-types-plugin


text:
安装不了插件

描述一下这个bug
用的 Windows11，打开插件中心显示 no data 。
复现方式

进入“插件中心”。

预期行为
能够安装插件。
截图

@LinHQ1999 rubick 由于本人囊中羞涩，服务器已欠费。目前已基于 npm 重新设计了一套插件管理体系，另外为了减少按照包的大小，把超级面板抽离成了系统插件支持。欢迎前往体验 Rubick 2.0

明白了🤣

@LinHQ1999 rubick2 已合入rubick master 主干，未来还是在这个项目维护，不需要再切到 rubick2.0 上了

repo: rubickCenter/rubick


text:
[Fix #144] false positive for Rails/ReversibleMigration

Fixes #144
I've made this commit based on change_column_default logic, so I'm not sure if the pattern is the best one.
I've also thought about grouping the checks from change_column_default, change_table_comment and change_column_comment into a more generic check that looks if a method has a hash with :from/:to keys, but I'm not sure if it's the best approach. Let me know which way is better :)

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[x] Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

Below is a similar PR under review.
https://github.com/rubocop-hq/rubocop-rails/pull/136/files#r341516733
I think it needs to be checked that :from and :to options are included.

@koic I've updated the code based on PR #136, let me know what you think :)

authors: DNA koic

repo: rubocop-hq/rubocop-rails


text:
unknown keywords: permitted_classes, permitted_symbols

Testing Rails alpha with ruby-2.6.0-preview3
RuboCop added in gemfile from the master branch
Error:Rubocop returned exit code: 2
stderr:
unknown keywords: permitted_classes, permitted_symbols
/home/user/.rvm/rubies/ruby-2.6.0-preview3/lib/ruby/2.6.0/psych.rb:328:in `safe_load'
/home//user/.rvm/gems/ruby-2.6.0-preview3@gemset/bundler/gems/rubocop-4d8cd4153928/lib/rubocop/config_loader.rb:189:in `yaml_safe_load'
/home/user/.rvm/gems/ruby-2.6.0-preview3@gemset/bundler/gems/rubocop-4d8cd4153928/lib/rubocop/config_loader.rb:162:in `load_yaml_configuration'
/home/user/.rvm/gems/ruby-2.6.0-preview3@gemset/bundler/gems/rubocop-4d8cd4153928/lib/rubocop/config_loader.rb:41:in `load_file'
/home/user/.rvm/gems/ruby-2.6.0-preview3@gemset/bundler/gems/rubocop-4d8cd4153928/lib/rubocop/config_loader.rb:83:in `configuration_from_file'
/home/user/.rvm/gems/ruby-2.6.0-preview3@gemset/bundler/gems/rubocop-4d8cd4153928/lib/rubocop/config_store.rb:44:in `for'
/home/user/.rvm/gems/ruby-2.6.0-preview3@gemset/bundler/gems/rubocop-4d8cd4153928/lib/rubocop/target_finder.rb:110:in `excluded_dirs'
/home/user/.rvm/gems/ruby-2.6.0-previ ...

RuboCop version
0.60.0 (using Parser 2.5.3.0, running on ruby 2.6.0 x86_64-linux) from master branch

unknown keywords: permitted_classes, permitted_symbols

For these kwarg names change, The PR #6470 will not add the new conditional branch using Gem::Version.new(Psych::VERSION). It is the same as for the following reasons.

Because the kwargs API was not included in the latest stable psych gemrelease, 3.0.3:
https://github.com/ruby/psych/blob/v3.0.3/lib/psych.rb#L318
It's only been a part of beta releases of the next minor.
No real user will be affected by the API change.

https://github.com/ruby/psych/pull/378#issuecomment-437551151
Thank you.

authors: koic reckerswartz

repo: rubocop-hq/rubocop


text:
Update Rails/PluckInWhere to check for .ids call

Fixes #1213.

Thanks!

authors: fatkodima koic

repo: rubocop/rubocop-rails


text:
Remove coverage measurement for Edge RuboCop and RSpec 4 jobs

This PR is remove coverage measurement for Edge RuboCop and RSpec 4 jobs.
Coverage measurements are performed only in Test coverage job, so unnecessary measurements are stopped.

Before submitting the PR make sure the following are checked:

[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[-] Added tests.
[-] Updated documentation.
[-] Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
[x] The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

[memo] Perform only on test coverage jobs.
https://github.com/rubocop/rubocop-rspec/blob/d179b8b0238ea1bb01fc2ac6a31289f28389c770/.github/workflows/main.yml#L45-L54

Thank you!

authors: pirj ydah

repo: rubocop/rubocop-rspec


text:
Update auto-gen-config's auto-correction comments

This is a follow-up to https://github.com/rubocop/rubocop/pull/10384, following a suggestion from bbatsov in the code review.
Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!

authors: koic maxjacobson

repo: rubocop/rubocop


text:
Resolves #4739

Resolves #4739
Description

Remove product drive delete capability if there are any donations for the product drive.

Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Add new tests for product_drive_system_spec.rb

Looks OK, but has a request (hah) about the tests. @cielf this accomplishes the goal by hiding the button rather than having a backend validation - is that good enough?

Hmm.  All other things being equal, I would prefer the somewhat safer solution.   Do I think it's going to be an issue before such time as we would want to add deactivation?   Nope.   So I guess I'm ok with going forward with it if @dorner is.   Should we add some warning comments?

Hey, @cielf and @dorner!! :bowtie:
I made a few changes. I thought about keeping the "ProductDrive#can_delete?" method as it was and doing all the validation in the controller, but that way it would still be possible to delete a product drive with donations from the Rails console. So I took another approach.
I don't know why a test broke, locally it's working.

@jorgecoutinhobr Hey there!   Just checking in - will you be able to address the issues raised above soon?   If not, I'd like to pass this to someone who can finish this off, as this fixes a high-impact (albeit low likelihood)  issue.

authors: cielf jorgecoutinhobr

repo: rubyforgood/human-essentials


text:
Games and competition database

Store games + competitions to couchbase, restore on server boot
Cloned sueca with only 3 cards (mini-sueca)
Pass previous game to new game in competitions (allowing to correctly switch the initial player in the next game for example)

Hi, thank you very much for the pull request! :)
One thing, can you cherry pick your commits in order to remove the one where mini-sueca is added? Although I understand you may use it for testing bots, it doesn't feel right to be maintained in the main repo as it's not a "known" game.

One thing I'd like to keep is the ability to launch the server without a running database. Is that possible right now?

I removed mini sueca and optionally enabled database storage
All the other comments should also be addressed now :smiley:

Two things about the database:

The code isn't creating the bucket in Couchbase in the first place. When I start the server with an empty database I get a bunch of database errors mentioning that, preventing it from both retrieving and storing data;
Can you make the database feature disabled by default? The reasoning for that is that people that grab the code for the first time and run it would like to see the server in action with the minimum amount of work possible.

Other than that and the two new comments I did above, everything looks good to me :) Once I get the DB working here I'll merge this.

It's possible to create a bucket through the server, but I would argue against this.
We would need to pass the couchbase administrator username & password in the configurations, and create a bucket with some default settings for the user.
I guess it would be a nice to have, but the user should set up the bucket beforehand (it's a pretty straightforward wizard in the couchbase UI)

Ok, I didn't know what was involved, fair enough ;) But can we at least verify that the bucket exists and issue a warning when it doesn't? Right now an (async) exception is being thrown each time the server tries to save or restore stuff, but it should just warn the user and fall back to the noop behavior, shouldn't it?

After I created a bucket manually, I got the exception Unhandled rejection Error: No primary index on keyspace default. Use CREATE PRIMARY INDEX to create one. Does creating an index require admin credentials too, or it can be verified and created automatically by the server?

Checking the docs, I see that we should always pass user + password to openBucket
I will try to pass these configs, along with proper initialisation.
Creating the index shouldn't require password if the bucket isn't protected, but it's tricky query

Thanks :) I'm asking this because I'm having the same questions myself configuring the database locally. I think the idea should be to make using the database as simple as possible - of course some DB configuration steps should be done outside the botwars server (and those could be covered with documentation later), but ideally they should be as minimal as possible.
One problem with having the username and password in config.json is that the file is visible both server and client-side, which is an obvious security problem. But if it makes sense for the server to have the server credentials don't worry and use config.json - I'll have to separate server and client-side configs sooner or later.

Please check database.js again. I had to refactor it since the cluster.openBucket() has some bad API design: it synchronously returns a bucket, but must receive a handler when http communication occurs later to solve any errors.
I changed the database object to first resolve the databaseInstancePromise and only then execute the save() or getAll()
We should leave the login + create buckets + index to future improvements

Ok, I'll improve this later, as it's still yielding unhandled exceptions when the bucket exists but the index isn't created. Very nice work, thank you again! :)

authors: pedrorfernandes ruippeixotog

repo: ruippeixotog/botwars


text:
Remove unused arg in qdrant docs

Going through the docs I noticed a minor issue. It seems there is no port parameter, only url which can optionally include the port number.

@iansinnott nice catch, can you fix the conflict?

authors: EmanuelCampos iansinnott

repo: run-llama/LlamaIndexTS


text:
[Question]: Sql  mutiple table

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
How can I use LlamaIndex to query multiple tables from a SQL database schema? The schema contains several tables, and I need to efficiently query and retrieve data from them.

@dosu how to add prompt for the above case


text:
Fix: Error when parse file using SimpleFileNodeParser and file's extension doesn't in FILE_NODE_PARSERS

Description
This PR is a patch for issue #13152 .
The problem is currently, if file extension is unsupported. It will add document to list of nodes that make code crash
Fixes # (issue)
https://github.com/run-llama/llama_index/issues/13152
New Package?
N/A
Version Bump?
N/A
Type of Change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Added new unit/integration tests
[ ] Added new notebook (that tests end-to-end)
[ ] I stared at the code and made sure it makes sense

Suggested Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added Google Colab support for the newly added notebooks.
[ ] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I ran make format; make lint to appease the lint gods

@logan-markewich I removed metadata check from unittest because code under SimpleFileNodeParser class doesn't add extra metadata to documents / nodes


text:
Update Standalone ToA Points tracker

Adds pets, cleans up some files, adds an icon.

Are you using src/main/java/com/tuna/toa/icons/Tumeken's_Guardian.png and src/main/java/com/tuna/toa/icons/Tumeken's_shadow.png? They are very large images that should be resized if used or deleted if not.

Are you using src/main/java/com/tuna/toa/icons/Tumeken's_Guardian.png and src/main/java/com/tuna/toa/icons/Tumeken's_shadow.png? They are very large images that should be resized if used or deleted if not.
whoops, I am not. Was added for an update I never ended up doing. Removed

authors: AbusiveTuna raiyni

repo: runelite/plugin-hub


text:
Update calculator-pro

Add Scientific Notation

Also includes commit eff5ade27df35cb89a2a33de2a5b650d0097f805


text:
docs: refresh contributing guide (windows dev setup and auto-gen cmd docs)

Issue #, if available: #942
Description of changes:

Update contribution docs to reflect changes over the past few months:

Windows dev setup
Doc updates when commands change

Testing done:

[x] I've reviewed the guidance in CONTRIBUTING.md

License Acceptance
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Funnily enough, fixing the docs CI job which is supposed to allow doc only changes to skip running the full e2e tests caused the full e2e tests to run

repo: runfinch/finch


text:
[Add] Mobbin

URL
https://mobbin.com/
Description of the above provided site
Mobbin is a hand-picked collection of latest design patterns from mobile apps that reflect the best in design.
Category
Frontend
Sub Category
design inspiration

Thank you, would you like to work on this?

can I work on it

can I work on it

Sure

authors: Oyebolade parma1111 rupali-codes

repo: rupali-codes/LinksHub


text:
added subcategory

closes issue #2150
please merge this pull request @CBID2

created new pr

@CBID2
He created two PRs, we can go ahead with that. I'm closing this.


text:
'Node.unwrap_tags' accepts only 'list' as argument

Hi,
I don't know if this has any effect, but 'Node.unwrap_tags' should accept any iterable rather than only lists.
The following exception is raised when calling Node.unwrap_tags with a set:
    html.body.unwrap_tags({'a', 'span', 'div',})
TypeError: Argument 'tags' has incorrect type (expected list, got set)

I'm not sure if it makes sense to allow arbitrarily iterables. It's strongly typed for speed.

Got it. I'm willing to work under some constraints if it make things faster.

repo: rushter/selectolax