HttpResponseException do not reach Exceptions\Handler.php class

When A FormRequest throws HttpResposeException It is not been handled by Exceptions\Handler.php The render method is not even touched.

Yes, this is intended. An HttpResponseException already has the response contained with in it.

That response is used.

@GrahamCampbell ok so how do I make my default 403.blade.php visible if a FormRequest authorize method return false?

Which laravel version please?

5.1

There is no work around in Laravel 5.1 I'm afraid. Sorry.

I the router, we have this code:
    /**
     * Run the route action and return the response.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return mixed
     */
    public function run(Request $request)
    {
        $this->container = $this->container ?: new Container;

        try {
            if (! is_string($this->action['uses'])) {
                return $this->runCallable($request);
            }

            if ($this->customDispatcherIsBound()) {
                return $this->runWithCustomDispatcher($request);
            }

            return $this->runController($request);
        } catch (HttpResponseException $e) {
            return $e->getResponse();
        }
    }

In Laravel 5.2, that's abstracted to the exception handler, so you can hack the beahviour much more easily.

ok. Will figure it out somehow. But It will be great if you consider my pr https://github.com/laravel/framework/pull/11530 for v5.2.* or v5.3

The idea is that you render that view you want in the forbiddenResponse method. If you don't want that, then I'd recommend not using form requests.


add upstream changes from kayak/pypika #794 - Improve parameterized q…

This PR adds the upstream changes proposed in the upstream PR on pypika - Improved Parametrized query support.
This functionality will make it easier to parametrize arbitrary queries that are still missing parametrization in tortoise, e.g. SELECTs, etc. (See https://github.com/tortoise/tortoise-orm/issues/19 , https://github.com/tortoise/tortoise-orm/issues/81)

Thank you @long2ice ! Could you please create a new revision of pypika-tortoise for pypi etc. so that it can be integrated into tortoise-orm? 😄


add prod app in manifest

To deploy at prod environment, added manifest.
When this code will merge to main, expected 4 stages passed.

Codecov Report

Merging #136 (d08c2af) into main (5d30593) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #136   +/-   ##
=======================================
  Coverage   96.18%   96.18%
=======================================
  Files           5        5
  Lines         288      288
=======================================
  Hits          277      277
  Misses         11       11

Continue to review full report at Codecov.

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

IBM Cloud toolchain: Delivery Pipeline deployed promotions to dev, including commit 86f0b8ca3e3c474ad134ce36038d51394796f7f5


E2E tests fail because of wrong playwright version installation

Describe the Bug
I have discovered a bug when installing the required packages for e2e testing locally, different versions are installed than in the dockerfile which is pinned on playwright 1.35.0 but in the requirements txt its >=1.25.1 which seems to install something above 1.42
Steps to Reproduce the Problem
./install.sh
pip list
observe the packages and also run e2e.sh to see that the tests fail.
Expected Result
tests pass
Actual Result
tests fail
PermaplanT version
master
Operating System
Devcontainer
Browser
doesnt matter
Versions of other relevant software/extensions
No response
Additional info/logs
No response

It looks like some higher playwright versions have introduced breaking changes to our tests.

Thx for reporting this problem!
Does #1201 fix this issue?

Thank you, well done! :heart:


version 2.0 is incompatible and breaks groovy-postbuild plugin

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?
doesn't matter
Reproduction steps
https://github.com/jenkinsci/groovy-postbuild-plugin/blob/6eeecb7aeac5faa75313280ad67ad4c938e5bdc0/src/main/java/org/jvnet/hudson/plugins/groovypostbuild/GroovyPostbuildRecorder.java#L214 creates a new instance of BadgeSummaryAction
I don't know the exact conditions when the code is called but it results in this stacktrace
[2024-09-18T03:04:30.919Z] java.lang.NoSuchMethodError: 'void com.jenkinsci.plugins.badge.action.BadgeSummaryAction.<init>(java.lang.String)'
[2024-09-18T03:04:30.919Z] 	at PluginClassLoader for groovy-postbuild//org.jvnet.hudson.plugins.groovypostbuild.GroovyPostbuildRecorder$BadgeManager.createSummary(GroovyPostbuildRecorder.java:214)
[2024-09-18T03:04:30.919Z] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2024-09-18T03:04:30.919Z] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

Expected Results
badge is properly created
Actual Results
build fails
Anything else?
No response
Are you interested in contributing a fix?
No response

My suggestion is to upgrade the groovy-postbuild-plugin in order to be compatible (I had that on my bucket list anyway). WDYT?

definitely a solution

Once groovy-postbuild is adjusted I think the release notes should be updated to mention that groovy-postbuild must be updated as well

A pre-release of the groovy postbuild plugin is available for testing.  Use the "Jenkins Incrementals Publisher" tab to access the most recent build.

Thanks @MarkEWaite. The most recent build fixes the issue.

Fixed in release 264.vf6e02a_77d5b_c of the groovy postbuild plugin.


Why the JBoolean falseByte is 2 ?

public static JBoolean afunc(){
    return false;
}

Hi, Thank you for sharing the project.
Currently I have a problem. When I use JBoolean as the return value, it is always true. I found in jni's code that the returned value is 2. So, why is it set to 2 instead of 0? When I set falseByte to 0, the jni code works fine.
private static readonly Byte trueByte = 1;
private static readonly Byte falseByte = 0; // old is 2

Yes is a typo. jni.h
#define JNI_FALSE 0
#define JNI_TRUE 1

By now I'm working in a full JNI solution many bugs here may have now been resolved there.

OK, thank you.


[stable/prometheus-operator] Add a rule used by grafana dashboards

What this PR does / why we need it:
Several grafana dashboards installed with stable/prometheus-operator make use of the
following prometheus rule:
node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate

This rule is not anymore present so added it back.
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

Nervermind, already fixed by https://github.com/helm/charts/pull/18375


✨ Show the number of Orphaned/Archived rules next to the links at the bottom

Cc: @bradystroud @adamcogan @BrookJeynes @jaydenalchin
Hi team,
Pain
Ideally we shouldn't have any orphaned rule...

Do you think we should include the number of existing orphaned rules?
Would we be able to hide this link if the number is 0?
Do you think we should include the number of current archived rules?

😟 Orphaned Rules (53)  . . . .  📦 Archived Rules (148)  . . . .   ⏸ Unmigrated Rules

Thanks!

Hey Tiago,
Completely agree that ideally we wouldn't have any orphaned rules!
My understanding is we just added the orphaned page to catch & fix orphaned rules since we made it possible to archive categories.

Would we be able to hide this link if the number is 0?

I think this is an awesome suggestion, and would prefer this as a clean, quick and easy way to see if any exist + need attention (vs showing the numbers).
I would be most concerned with showing the number of archived rules as that could (and should) get exponentially large over time.

Hey @jaydenalchin / @BrookJeynes
I understand JD's point, but I don't think showing those numbers to be concerning. They quickly bring useful information and are already subtle enough at the bottom of the page...
My vote is to:

Show the numbers of "Archived" and "Orphaned"
Hide "Orphaned" if = 0

@bradystroud / @adamcogan
Thoughts?

Update: As of June 24th 2024 we have no Orphaned Rules...
The link https://www.ssw.com.au/rules/orphaned/ should be updated
from

to:

✅ There are no orphaned rules! Go to SSW Rules to find one that can make your work better.


Private Browsing with i2p a'la Brave

Starting from regular browsing, open "Private Browsing with I2P" mode.  Also solves my plugin updates without outproxies issue(#4) but maybe creates another one(#6)? Solve #1 first.

Started working on this in the contextual-ids branch. Will probably also finish the Chromium parts there.

Very close, but super complicated to do for both Firefox and Chrome at the same time.

Will be closed by #8


reviewed identation point and consistency of systemd journal writing

@hugovalente-pm : Is this blog from Costa? It is really really long, I am not sure who will read till the end..

@hugovalente-pm : Is this blog from Costa? It is really really long, I am not sure who will read till the end..

the blog is from you 😂

jokes aside, it was something @Aliki92 released here https://github.com/netdata/blog/pull/331


Option to revert to the legacy UI of PowerRename from v0.47.1

Description of the new feature / enhancement
Since v0.49.0, PowerRename UI has been overhauled to better fit the Windows 11 UI / UX.
Arguably, this looks a better UI design however from productivity perspective, the UWP look and feel does not fit very well if the tool being an essential daily driver. UI scaling is unstable, some options are less straight forward (e.g. lower / upper / capital case, which require :hover tooltip to understand), some require extra steps to produce the same output (e.g. dropdown vs. ticks previously).
As a result, few users from our group have attempted to adapt to the new UI, but all ended up have to rollback to v0.47, as the new UI is affecting how quickly the renaming operation can be done.
Hence it would be good to allow the legacy UI or version of Power Rename to be selectable (even if the legacy version is not being maintained anymore), while not necessarily for the user to lock themselves onto certain version to avoid receiving updates on other utilities.
Scenario when this would be used?
It worth note unlike other utility such as color picker or fancy zones, utility on batch file processing (e.g. Total Commander, Bulk Rename Utility) usually does not require a super fancy UWP-like UI, because it needs to do job fast and robust enough while offers a higher degree of versatility without the process to interpret what each icon represents. Icons :selected or not can be easily missed vs. some simple ticks, due to the fact that each file renaming scenario could be massively different.
Looking at commercial products like Bulk Rename Utility (BRU), its UI and UX have been super robust for many years, but it has 2 issues for relatively light-weight users:

It has to operate in full or large window in order to gain the full picture;
It has too many options designed for some very specific purpose, which many in everyday task are not necessary;

Based on the issues above, Power Rename has been a superb alternative to BRU whilst offers the minimum required options and a fast, widget-like experience, but the new UI are now holding the experience back to the point we have to choose between legacy Power Rename and BRU.
Supporting information
A similar UI / UX debate in the past year is regarding Adobe had set the default option of "Ctrl + Shift + S" to "Save a copy" from previously "Save as", which caused a wave of frustrations. Eventually this is solved by keeping the widely acceptable mechanism as a legacy option (e.g. https://taylorhieber.co/how-to-save-a-jpeg-in-photoshop-with-save-a-copy-or-legacy-save-as/).
Appreciate this is not a case-to-case example, but it demonstrates how simple new UI / UX tweaks could break the existing workflow and cause frustrations for people relying on it as productivity drivers. Hence like the Photoshop example, would be good if legacy Power Rename can be made into a selectable option.

some options are less straight forward (e.g. lower / upper / capital case, which require :hover tooltip to understand), some require extra steps to produce the same output (e.g. dropdown vs. ticks previously).

CC @niels9001 knows I haven't been a fan of the UX and I've been advocating check boxes and such.


Does SEI in VS mode use default priority?

On page 74:

Major interrupts outside the priority-confi gurable subset can still be directed to VS level, but their priority will simply be the default order defi ned in Section 5.1.

But SEI is also not in the subset of major interrupt numbers listed on page 73:

1 Supervisor software interrupt
5 Supervisor timer interrupt
13 Counter overfl ow interrupt
14–23 Reserved for standard local interrupts

So I wonder whether SEI in VS mode uses default priority.

The statement on page 74 about major interrupts outside the priority-configurable subset using the default priority order is a part of scenario 4 in Section 6.3.3, where hvictl.VTI = 0. However, the priority of a VS-level supervisor external interrupt (SEI) is determined by the first three scenarios in Section 6.3.3. Therefore, the priority of an SEI in VS-mode is not always based on the default priority order, as it depends on the specific conditions outlined in scenarios 1, 2, and 3 of Section 6.3.3.

Yes, follow the rules in Section 6.3.3.  Comments like the one quoted at the top (about the "major interrupts outside the priority-configurable subset") are intended to be helpful, but the normative text (not in comments) has priority.
Modifying the quoted comment to account for SEI would make it more complicated, which may be worse for understanding.  I'm not sure I know how to make it better.


python312Packages.marimo: 0.3.4 -> 0.3.5

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.marimo is: A reactive Python notebook that's reproducible, git-friendly, and deployable as scripts or apps
meta.homepage for python312Packages.marimo is: https://github.com/marimo-team/marimo
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.3.5 with grep in /nix/store/s3cayl27gj3ds5x6zgrrm2nxlrsa699b-python3.12-marimo-0.3.5
found 0.3.5 in filename of file in /nix/store/s3cayl27gj3ds5x6zgrrm2nxlrsa699b-python3.12-marimo-0.3.5

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

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
marimo
python311Packages.marimo
python312Packages.marimo

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/s3cayl27gj3ds5x6zgrrm2nxlrsa699b-python3.12-marimo-0.3.5 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/2705d2a12372fed761014ef9922f2d8737c6ed98#python312Packages.marimo

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/s3cayl27gj3ds5x6zgrrm2nxlrsa699b-python3.12-marimo-0.3.5
ls -la /nix/store/s3cayl27gj3ds5x6zgrrm2nxlrsa699b-python3.12-marimo-0.3.5/bin

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

4 packages built:

marimo (python311Packages.marimo)
marimo.dist (python311Packages.marimo.dist)
python312Packages.marimo
python312Packages.marimo.dist

Maintainer pings
cc @akshayka @dmadisetti for testing.

duplicate of https://github.com/NixOS/nixpkgs/pull/299671


one-file traildb

Package the whole TrailDB directory in a tarball, so that you can store a whole TrailDB in one file. Provide an index for the tarball for fast access to individual files.

Cleaning up old issues; one-file TrailDBs have been implemented and they are great.


RFP - unofficial-google-chat-

Checklist

[x] The package I am requesting does not already exist on https://chocolatey.org/packages;
[x] There is no open issue for this package;
[x] The issue title starts with 'RFP - ';
[x] The download URL is public and not locked behind a paywall / login;

Package Details
Software project URL :https://github.com/squalou/google-chat-linux
Direct download URL for the software / installer : https://github.com/squalou/google-chat-linux/releases/download/5.15.17-1/google-chat-linux_Setup_5.15.17-1.exe
Software summary / short description:
unofficial Google chat client wrapped in electron

The title of whatever package is created should reflect that is unofficial. My concern is that if there is an official google-meet package created in future, it will clash.
This may also cause some issues (take from https://github.com/squalou/google-chat-linux#readme):

There will be "SmartScreen" warning about how unsafe this .exe is, Windows pretending it has detected something nasty and is protecting you. I Don't Care and won't buy a certificate.

Is windows code signed app necessary?

Not necessarily. But Windows Defender loves picking up on unsigned apps. If it can be silently installed then it should be fine. It is something that needs to be taken into consideration though.


Improve typing for Ramda #pick.

There were some issues with the current definition for Ramda's #pick:

Would not correctly detect invalid keys, so the following would not fail

const pck2: Object = _.pick([ 'a', 'b' ], { a: 1 })

Did not allow passing in typed object literals (a very common use case), so something like this would fail when the keys had different types:

const pickedObj: { a: string, b: number, c: boolean } = { a: 'hello', b: 1, c: true }
const pck3: { a: string, b: number } = pick(['a', 'b'], pickedObj)

This PR addresses both issues.

Sweet fix! Could you rebase it when you get the chance?

Done!

Beautiful, approved.


[move-prover] Fixed some verification issues with the stdlib

(1) Resolved the precondition violation issue in LBR, Coin1, Coin2 by changing the invariant to a invariant module in RegisteredCurrencies.move
(2) Made the functions in FixedPoint32 "intrinsic"

Added uninterpreted procedures to prelude.bpl for this

After (1) and (2), Prover terminates on LBR and TransactionFee although it didn't previously.

However, LBR takes about 70 seconds, and TransactionFee takes 80 seconds, which is much longer than normal (< 30s).

Turned on the verification flag for Option.move
TODO: there is still a non-terminating issue in LibraAccount

Motivation
To fix some verification issues with the current stdlib
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
cargo test

LGTM. You can rerun cargo run in stdlib folder to regenerate the documentation.

Done.

@bors-libra r=emmazzz

:pushpin: Commit ced38b2 has been approved by emmazzz

:lock: Merge conflict

I don't quite know what's going on with stdlib.mv, but I'd try reverting that file from master (git checkout ) and submitting the fresh PR.  If that doesn't work, I think Tim answered the last question about it.

I think a competing PR was recently landed. Let me retry since I rebased.

@bors-libra retry

@bors-libra merge

@bors-libra r=emmazzz

:pushpin: Commit 6a324f8 has been approved by emmazzz

:hourglass: Testing commit 6a324f8b69e07364e3d0c4bb20e83b767ef1b556 with merge 5318a51dc89d7e52b1e0cae2a4d38f3921850282...

:broken_heart: Test failed - checks-circle_commit_workflow

@bors-libra r=emmazzz

:bulb: This pull request was already approved, no need to approve it again.

This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.

:pushpin: Commit 6a324f8 has been approved by emmazzz

:hourglass: Testing commit 6a324f8b69e07364e3d0c4bb20e83b767ef1b556 with merge 54ad28b8ff11cb09c017bc65e9cae052fad50303...

@bors-libra retry

:hourglass: Testing commit 6a324f8b69e07364e3d0c4bb20e83b767ef1b556 with merge abb1c82cd32b9251d71a01c2ab50c3075d52f5d0...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: emmazzz
Pushing abb1c82cd32b9251d71a01c2ab50c3075d52f5d0 to master...


Moved sqllab tests from core_tests to sqllab_tests

Why:

Since sql lab is a separate page, separating its endpoint tests to a separate file would make our tests cleaner and easier to add new tests

Done:

moved run_sql() to base_tests since it's used by both core_tests and sqllab_tests
moved sql lab related tests to sqllab_tests.py

needs-review @mistercrunch @bkyryliuk

minor comments, looks good overall !


Use GOOGLE_CLOUD_CPP_DEPRECATED for deprecated RPCs

RPCs can be annotated with option deprecated = true, e.g.:
https://github.com/googleapis/googleapis/blob/25d691b074e0b932e1c3f8a690ced8ddec8ae50e/google/container/v1/cluster_service.proto#L178-L194
For new libraries, we should not generate any RPCs that are deprecated, if necessary by adding them to the omit_rpcs list.  For existing GA libraries we should generate a @deprecated Doxygen comment, and (most likely) add the GOOGLE_CLOUD_CPP_DEPRECATED annotation, though this has problems with builds using -Werror.

For new libraries ...  For existing GA libraries ...

Right ... which in turn requires some way to distinguish those cases.  My only thought at the time was that any option deprecated = true RPC should be required to be listed in one of omit_rpcs (for new libraries) or a new "emit_rpcs" (for newly deprecated RPCs in existing libraries).

We still want this, but do not have time.

No time for this, to the backlog.

@dbolduc points out in #10573 that we also need to be wary of deprecated message fields that appear in google.api.method_signature options, and hence in RPC overloads.
If the field is newly deprecated, we've probably previously released its overload, and so need to maintain that for backwards compatibility.  And in order to know that, we need long-term memory like the emitted_rpcs and omitted_rpc config elements.
And still, if we decide to generate code for a deprecated RPC, or an overload using a deprecated field, we want to add an @deprecated Doxygen comment and the GOOGLE_CLOUD_CPP_DEPRECATED annotation.

Aside: Note that the proto compiler already adds PROTOBUF_DEPRECATED (__attribute__((deprecated))) to the accessors for deprecated message fields.

Removing from backlog, because I duped the issue.


snore: init at 0.1

Motivation for this change
Add https://github.com/clamiax/snore
Fixes https://github.com/NixOS/nixpkgs/issues/71269
cc: @MicrosoftTakeover
Things done

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

[X] NixOS
[X] macOS
[ ] other Linux distributions

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

Notify maintainers
cc @

LGTM, tested with sandboxing


Feature/datadog metrics

Hello
This module is for querying datadog metrics and checking if metric data points match some threshold.
Ex.
steady-state-hypothesis:
  title: Check if the application doesn't have 5xx errors
  probes:
  - name: deployment doesn't have 5xx errors
    type: probe
    tolerance: True
    provider:
      type: python
      module: chaosdatadog.metrics.probes
      func: get_metrics_state
      arguments:
        query: cumsum(sum:istio.mesh.request.count.total{kube_service:test,response_code:5*}.as_count())
        comparison: '<'
        threshold: 30
        minutes_before: 10

[x] Check if the datadog metric exist.
[x] Query the metric and extract the datapoints.
[x] compare all the datapoints with the threshold number
[x] Add unreleased comparison to CHANGELOG.md
[x] Create metrics module tests
[x] Enjoy coding this beatiful framework !!!

Thanks.

Also linter seems to indicate some errors if you can check them.


Optimize and cache colonist bar colonist drawer patch

Fix for accidental wrong merge before. This optimizes drawing the icons on the colonist bar by loading traits (including custom class traits) into a dictionary and using that to check for icon rather than sequential if elses. On top of that it then caches the response for 5 seconds so it can skip the trait and hediff checking most of the time since colonists dont change that frequently.
Note there is a change to how custom classes are recognized by the patch. Instead of using their Comp, it relies on a unique trait. A warning has been added if the traits overlap with another mod. I have tested with a bunch of custom classes on workshop and did not see any issues. Note with the caching there is a maximum of 5 second delay before the icon appears/disappears with the trait.
Average ms reduction increases with the number of colonists where it's not an improvement at 3 colonists, but becomes significant around 6 colonists. around 40 the time for the function went from average of .450ms to .3ms.

TraitIconMap.cs might actually be better to be converted to a static TraitCollections that holds the icon dictionary as well as a set for Magic Traits and one for Might Traits (including custom classes populated in the same way as this PR). That way functions like IsMagicUser can just check the HashSet and then the wayfarer exception rather than a bunch of if statements that need to be updated whenever a class is added.

Probably should also rename SimpleCache to DatetimeCache since the other more common caching strategy in rimworld is caching by world ticks.

Accepted


Maillist IMAP heading to info box

This corrects the double heading display of the IMAP server. Final result is one heading followed by an information box.
Relevant post at http://www.elkarte.net/community/index.php?topic=3324.0

:+1:


Retry in Service Bus is not working

@azure/service-bus:
^7.4.0:
MAC:
[x] nodejs

16.13.1

Describe the bug
I am trying to make a auto retry for failed messages in service bus. But seems like the SDK is ignoring the retry configuration provided, and its always retrying for 10 times.
To Reproduce
Steps to reproduce the behavior:
const { ServiceBusClient, RetryMode } = require("@azure/service-bus");

const SERVICEBUS_CONNECTION_STRING="<Connection String>";

const QUEUE_NAME = "<queue name>";

const sbClient = new ServiceBusClient(SERVICEBUS_CONNECTION_STRING, {
  retryOptions: {
    mode: RetryMode.Exponential,
    maxRetries: 3,
    retryDelayInMs: 10000,
    maxRetryDelayInMs: 10000
  }
});

const receiver = sbClient.createReceiver(QUEUE_NAME);
const sender = sbClient.createSender(QUEUE_NAME);

const subscription = receiver.subscribe({
  processMessage: async (brokeredMessage) => {
    console.log(`Received message: ${JSON.stringify(brokeredMessage.body)}`);
    throw new Error("Test Error");
  },
  processError: async (args) => {
    console.log(`Error from source ${args.errorSource} occurred: `, args.error);

    // the `subscribe() call will not stop trying to receive messages without explicit intervention from you.
    if (isServiceBusError(args.error)) {
      switch (args.error.code) {
        case "MessagingEntityDisabled":
        case "MessagingEntityNotFound":
        case "UnauthorizedAccess":
          // It's possible you have a temporary infrastructure change (for instance, the entity being
          // temporarily disabled). The handler will continue to retry if `close()` is not called on the subscription - it is completely up to you
          // what is considered fatal for your program.
          console.log(
            `An unrecoverable error occurred. Stopping processing. ${args.error.code}`,
            args.error
          );
          await subscription.close();
          break;
        case "MessageLockLost":
          console.log(`Message lock lost for message`, args.error);
          break;
        case "ServiceBusy":
          // choosing an arbitrary amount of time to wait.
          await delay(1000);
          break;
      }
    }
  }
});

Expected behavior
The message should be retried only 3 times with a delay of 10 seconds.

@krisalay thank you for reporting this issue!  We will have a look shortly.  Would you mind telling us on which error code you were retrying?

Hi,
This is still happening in version 7.7.2. ie, it keeps retrying infinitely.


OSS vulnerability enrichment

First of all, thanks for this great project 👍🏻
We want to hear from you, so I'd like to ask about a new feature. Do you plan to improve vulnerability reports for OSS? For example, it would be nice to know what open-source project is related to the CVE (apart from CPE as the relation is indirect) + a reference with a tag that shows which commit introduced the vulnerability, and which commit fixed this vulnerability. Such data would be a huge help for ML models in finding and fixing new vulnerabilities.
Disclaimer: I worked on a research for fix commits, and I can share it if it's useful (the link is not here to prevent self-promotion)

Hello and thanks for the feedback. While I agree that identifying upstream open source components and cause/fix commits would be very helpful, that information is rarely available in the information we have access to when analyzing reports. And researching that information manually is expensive. So, probably out of scope for the current vulnrichment project.
Does your research automate the discovery of fix commits? This I assume? https://github.com/JafarAkhondali/Morefixes
There are discussions underway in the CVE ecosystem about how to capture and convey what I'll call "VEX-like" information: how software is affected (or not) by a vulnerability in an upstream component. If this progresses, vulnrichment might integrate VEX/upstream information in some way.

Yes, that's the research. Thanks for the information! I understand. By the way, are you planning to add a link to the "POC" or "POCs" as well instead of only saying "exploitation" in SSVC ?

Agreed that it's great feedback, but I do believe this is out of scope for the CISA-ADP, since we're pretty restricted (self-imposed and by the CVE board, jointly) on what we can add to our ADP container. That said, we can keep this open for another few days for more discussion.


Remember resized maximized panel's height

Currently, I get 30% height terminal when I do Ctrl + `, and 90% height terminal when I do "Toggle Maximize Terminal".
If i try to resize the panel, I only get to change the height of the "default height" for terminal.
Let's say:

I run "Toggle Maximized Terminal"
I resize it to 60% height
"Toggle Maximized Terminal" should toggle between close state and 60%
"Toggle Terminal" should toggle between close state and 30%

However, current behavior is "Toggle Maxmized Terminal" will always go to 90% height, which I don't want.

I think I'm seeing the behavior described here as well, and to me it's also confusing. What's happening is the terminal seems to forget its previous size if I try to toggle between three states: closed, maximized and a third size (in my case usually around 30-50%). Here's a gif that shows the behavior:

What I'm doing in this screen recording is the following:

Open a VS Code window with a terminal pane sized at around 30%.
Toggle the terminal a couple of times. It remembers the size it was, and goes back and forth between that size.
Toggle between normal and maximized a couple of times. It remembers again.
From maximized, toggle to closed and back. When it comes back, it's not maximized, but at 90%, and my previous size is now forgotten and there's no way to get back to it without using my mouse.

In other words, the problem seems to be that closing a maximized terminal sets the "previous size" to 90%, instead of whatever it was before the panel was maximied.
If this is a different problem from the one you tried to describe, @octref, let me know and I'll file a separate issue for it.

@tomasaschan the issue you are reporting is covered by #80366

@sbatten Thanks; I'll keep a lookout for a fix there then!


Space bar and Backspace keys work like Left and Right

I want to add it because based on https://github.com/swcarpentry/slideshows/pull/22.
This should not be difficult to implement taking  https://github.com/imakewebthings/deck.js/pull/43. as starting point.

@r-gaia-cs The "next" keys already default to Enter, Space, Right, Down, and PageDown, and the "previous" keys default to Backspace, Left, Up, and PageUp. Are you seeing something different?

@imakewebthings Thanks for the feedback. The slides that I got was using a old version. Sorry to the trouble.


how to add other dataset?

Hi, I want to train on diffierent dataset, so what should I modify?
Looking forward to your reply.

Hi, you can refer to https://github.com/facebookresearch/maskrcnn-benchmark/issues/15 for more details.

Thanks you very much!

修改paths_catalog.py和类别数量后，运行：
dataset_name coco_2014_train
loading annotations into memory...
Done (t=4.41s)
creating index...
index created!
dataset_name coco_2014_trainval
loading annotations into memory...
Done (t=5.22s)
creating index...
index created!
dataset_name coco_2014_val
loading annotations into memory...
Done (t=0.55s)
creating index...
index created!
datasets [<maskrcnn_benchmark.data.datasets.concat_dataset.ConcatDataset object at 0x7fb07c085fd0>]
dataset <maskrcnn_benchmark.data.datasets.concat_dataset.ConcatDataset object at 0x7fb07c085fd0>
Traceback (most recent call last):
File "tools/train_net.py", line 171, in
main()
File "tools/train_net.py", line 164, in main
model = train(cfg, args.local_rank, args.distributed)
File "tools/train_net.py", line 60, in train
start_iter=arguments["iteration"],
File "/home/disk2/gg/msrcnn/maskscoring_rcnn/maskrcnn_benchmark/data/build.py", line 157, in make_data_loader
sampler = make_data_sampler(dataset, shuffle, is_distributed)
File "/home/disk2/gg/msrcnn/maskscoring_rcnn/maskrcnn_benchmark/data/build.py", line 62, in make_data_sampler
sampler = torch.utils.data.sampler.RandomSampler(dataset)
File "/home/disk2/anaconda3/envs/maskrcnn_benchmark/lib/python3.6/site-packages/torch/utils/data/sampler.py", line 66, in init
"value, but got num_samples={}".format(self.num_samples))
ValueError: num_samples should be a positive integer value, but got num_samples=0
请问您在训练自己数据的时候还改了什么么？给的链接挺麻烦的？


Add cargo xtask export command

Closes #34.
One of the advantages is that we can release ac-library.rs as a single file with GitHub Releases.
Instead, the CI will take longer. I don't think we will need this tool soon (though an ABC will be held tomorrow), so I'll keep this PR draft.
$ cargo xtask export | xsel -ib # to the clieboard
   Compiling xtask v0.0.0 (/home/ryo/src/github.com/rust-lang-ja/ac-library-rs/xtask)
    Finished dev [unoptimized + debuginfo] target(s) in 1.67s
     Running `target/debug/xtask export`
    Expanded /home/ryo/src/github.com/rust-lang-ja/ac-library-rs/src/lib.rs (46161 B)

https://github.com/atcoder/ac-library/issues/20

atcoder/ac-library is trying to

provide the everything combined header file so that we can use AC Library by just copy-paste it to the top of main.cpp

Why don't we provide such a combined file.


Broken DI registration

Recently introduced change https://github.com/MassTransit/MassTransit/commit/a949fff8394259c337377fb7ae422f655e7dbc87 caused change in behavior. So far using services.AddMassTransit(createBus) was effectively doing services.TryAddSingleton<IBusControl>(createBus) while right now it's services.AddSingleton<IBusControl>(createBus). The problem is especially visible when trying to run integration tests, where you usually set up InMemory bus and run Startup of the application under test (which then might try to add RabbitMQ bus etc.) So far the behavior was correct: as the bus was already registered (InMemory) nothing was "overwritten" but right now the latter registration have a priority.

So, help me understand why this is an issue.  That seems like a recipe for production failure at some point. Do you have an example where you'd want to add the bus to the container twice, and just use whatever is there if it's already setup?

OK, so let's assume we've got quite simple application, where we use MT (choosing Rabbit as a transport) and MT StateMachines (using Redis as a storage). Our Startup class will look like this:
services
    .TryAddSingleton<ISagaRepository<AbcMySaga>>(provider => new RedisSagaRepository<AbcMySaga>(...))
    .AddMassTransit(provider => Bus.Factory.CreateUsingRabbitMq(bfc => {
        var host = bfc.Host(...);

        bfc.ReceiveEndpoint(host, ..., rec => {
            rec.ConfigureSaga<AbcMySaga>(provider);
        })
    }), c => {
        c.AddSagaStateMachine<AbcMyStateMachine, AbcMySaga>();
    });

Everything is nice and clean. Now, let's add some integration tests to our application. We want to use InMemory repositories as well as InMemory transport for MT. Our test might look like this:
using (var bus = MassTransitTestHarness.Create("sample"))
using (var myAppFactory = new MyAppFactory(bus.BusControl, bus.Host))
using (var client = myAppFactory.CreateClient())
{
    var reponse = await client.PostAsync(...);

    // Assert something happened (e.g. new saga has been created and processed)
}

Here MassTransitTestHarness is responsible for creating InMemory bus tranport and MyAppFactory starts up our application with InMemory services (here: InMemorySagaRepository):
public class MyAppFactory : WebApplicationFactory<MyAppStartup>
{
    private readonly IBusControl bus;
    private readonly IInMemoryHost busHost;

    public MyAppFactory(IBusControl bus, IInMemoryHost busHost)
    {
        this.bus = bus;
        this.busHost = busHost;
    }

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        builder.ConfigureServices(services =>
        {
            services
                .AddSingleton<ISagaRepository<AbcMySaga>>(provider => new InMemorySagaRepository<AbcMySaga>())
                .AddSingleton(provider =>
                {
                    busHost.ConnectReceiveEndpoint(..., rec =>
                    {
                        rec.ConfigureSaga<AbcMySaga>(provider);
                    });

                    return bus;
                });
        });
    }
}

Using this design:

Application code is not obscured by integration testing code.
Integration test code only need to set-up what's really different from actual application (mostly some mocks and InMemory implementations). All other things are taken directly from application's Startup.

So far everything used to work brilliantly! Unfortunately right now call to .AddMassTransit() overrides already existing setup by calling .AddSingleton() instead of .TryAddSingleton() internally.
PS. Take a look at other .Add*() extension methods, like say .AddMvc(). It always .TryAdd*() instead of .Add*() for this very purpose: to allow end-user to override some specific services - no matter if we're dealing with integration tests and/or the application itself.

I will look at the other extensions, and see how they're using TryAdd, but your example like this one:
                .AddSingleton(provider =>
                {
                    busHost.ConnectReceiveEndpoint(..., rec =>
                    {
                        rec.ConfigureSaga<AbcMySaga>(provider);
                    });

                    return bus;
                });

Scares me beyond all end, because ConnectReceiveEndpoint() is an async method, and configure services in the container is not in a valid async context. So, yeah, I'd highly recommend against that, unit test or otherwise.
The TestHarness code was designed to test all consumer types in MassTransit, in isolation. Bringing the container into a unit test stinks to high heaven in my head, something I wouldn't do unless I was testing the container. Things like configuration code and container setup/use should be at the absolute outer skin of the application, and putting them in deep like this (even the receive endpoint configuration should be at that configuration level - using host/Connect feels like a hack here) smells.

While I agree TryAdd should probably be used as that matches what at least .AddMvc() does, a workaround and/or better approach would be to use IWebHostBuilder.ConfigureTestServices which is designed to allow you to override DI registrations as it runs later.

The usage of .ConnectReceiveEndpoint() is indeed a bad, really bad example. However we're talking about integration tests not unit tests here, so starting app the entire app with container is quite OK, I guess?

Yeah, and I'll get to looking at the Try (seriously, there is no try, only do, right) methods.

So your suggested changes are breaking the unit tests: https://ci.appveyor.com/project/phatboyg/masstransit/build/job/jv0xflpe67adypg3/tests
If you can figure out the issue and resubmit the PR, that would be great.

Hopefully the last commit resolves this to where it works for you.

Works fine! :)

@Crozin Im having the same issue, tried looking for your changes but cannot find them in master


@key but can't control GSI attributes

Is your feature request related to a problem? Please describe.
in schema.graphql, I am using @key to define a GSI (combining 2 fields in the table) for a dynamodb table.
The GSI is created along with the graphql and resolvers (which is exactly what I wanted and why I was creating through
amplify). But when looking at the GSI in dynamodb,  I want to set the read capacity, write capacity and auto-scaling.
Describe the solution you'd like
I want a mechanism to be able to specify the GSI parameters (just like if I was creating through the dynamodb interface).
Describe alternatives you've considered
Quitting using amplify ;-)
Additional context

You can now apply overrides via the amplify override api command. You can also manage these settings directly with our CDK construct.


updated saga.version

#21 @seanyinx

Coverage remained the same at 94.097% when pulling 14c29c5af454e75baa31c19a6e270653f818ddd7 on zhang2014:updated_sagaVersion into 5c35c940d833aa3755ebdebcb151ce6a0d693182 on ServiceComb:master.

@zhang2014 very elegant solution to refer saga.version to project.version


DOC Fix add image examples

Description
Uses add_image instead of view_image as per the text and title of the example.
Addresses #4911
Type of change

[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

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change
[ ] example: I check if my changes works with both PySide and PyQt backends
as there are small differences between the two Qt bindings.

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

I have no objections to this, but for me that raises the question of the utility of having add_* and view_*, and/or if we should advertise both methods in general.
So I'm going to approve, but let someone else make the decision of merging.

Thanks @Carreau
I also thought about the add_* vs view_* and now that I have read more of the examples I think the view_* is generally used. The times where add_* is used in examples is when a viewer has already been created. In the getting started/napari viewer tutorial page we also first introduce view_image and later mention that you can create an empty viewer then add images.
I will amend these examples to use view_* and happy to take suggestions/opinions.

Thanks @Carreau !

I'm only noticing this today, but my original intent with #4911 was to get an example for add_image to understand how to open an empty viewer and then open an image. Maybe it makes sense to have another example to illustrate the case I'm describing.

I agree, the napari.org homepage shows how to use viewer.view_image to open a viewer with an image. Using add_image is the more typical use case, because you want to add something to an existing viewer.
So the syntax of creating a viewer—with a name—and then reusing the viewer is pretty key.

Is it worth opening an issue to discuss whether the convenience of view_* is worth the user's confusion, and the added complexity to maintain/update codebase and docs ?

A quick solution to this:

add_image to understand how to open an empty viewer and then open an image

is that we could amend this example: https://napari.org/stable/gallery/get_current_viewer.html , adding to the end how to add an image layer after getting the current viewer.

@Carreau

Is it worth opening an issue to discuss whether the convenience of view_* is worth the user's confusion, and the added complexity to maintain/update codebase and docs ?

I feel like #4693 is that issue? 😊

add_image to understand how to open an empty viewer and then open an image

is that we could amend this example: napari.org/stable/gallery/get_current_viewer.html , adding to the end how to add an image layer after getting the current viewer.

I don't think that's a good solution because creating a viewer is a key step in Python. I don't like get_current_viewer as a general pattern, it's more of a last ditch attempt in cases where we really need to deal with state, such as plugins, which don't have access to the full runtime. In Python code using napari, we should always create the viewer, or get it as input to our functions.
But I'm hoping imshow followed by deprecation of view_ will go a long way here.

I'm not sure https://github.com/napari/napari/issues/4693 addresses:

Using add_image is the more typical use case, because you want to add something to an existing viewer.

for the above, we could amend the 'Add image' example to explain how to add another image to the existing viewer. Or make another example on how to add an image layer to an existing viewer?

Back in the very early days, if I remember correctly, our README had something like, "Here's how you make a viewer, which is the main object to interact with in napari. To add an image, you then use the "add_image" method. Because this is such a common pattern, we made a shortcut with the view_image function." So we should rework that with imshow and it should be pretty much on the front page imho.

So we should rework that with imshow and it should be pretty much on the front page imho.

Maybe this documentation update should be part of: https://github.com/napari/napari/pull/4928 ?

Maybe #4693 addresses that, but is it really that bad to have 2 lines instead of 1 ?

LOL Fair point @Carreau but I think the answer is yes, especially in interactive use. In code I always do fig, ax = plt.subplots(), but in IPython sessions I often just do plt.plot or plt.imshow(). I would appreciate if those gave me back the figure and axes to be honest! 😃 This also relates to #4740 — we really want to be able to offer a quick, light way to look at nd-images.
@lucyleeow

Maybe this documentation update should be part of: https://github.com/napari/napari/pull/4928 ?

Maybe but I'd say let's leave it until after. Scope creep in PRs is a pain for contributors. Typically if someone proposes a new thing in a PR and we're not sure about it, I'll ask for docs updates because it helps clarify the utility. In this case I'm really quite sure about it! 😂


Update repository after transfer

See https://github.com/senzing-garage/garage-roadmap/issues/3

Pull requests:

https://github.com/Senzing/g2-sdk-go/pull/113


Hi, everybody.

I am a dev who likes Astro framework very much.
I would like to discuss about the projects with stars of Astro.
Thank you for your reading.

Hello @Yaron-medusa! I believe the best way to get in contact with us and our community as a whole is through our Discord chat: https://astro.build/chat.
I'm closing the issue as it isn't related to the docs repo.


[5.4] Add ipv4 and ipv6 validations

This would probably be fine going to 5.3 as far as I can see.


Docs

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.
[x] The changes are appropriately documented (if applicable).
[x] The changes have sufficient test coverage (if applicable).
[x] The testsuite passes successfully on my local machine (if applicable).

Summarize your changes:

I know the commits look super weird on this PR, but we'll just squash and merge and it'll all be fine 😆

Current plan is to put a giant "THIS IS A WORK IN PROGRESS / BETA" banner on the top of the plugins docs page, just to give us time to play with / make work properly 😄

Only thing pending is filling out the landing page of https://v6.electronforge.io/ with some info or something 🤔
Probably just general overview of forge / project goals / link to Getting Started.  Can deal with that after this is merged


Custom Scaling Policies

Proposal
I want to scale my deployment based on metric so using KEDA but should be deployed in a different way. i want to restart all my deployment pods after each up scale / down scale. Reason for this is pod dependency on max replica count
Use-Case
ave containers running thread of my application acting as a consumer on database and processing records. I need to keep track of replicas and pass it as a parameter to my pods. The pods currently require 2 params to process records to avoid duplication.

Replica number
Max number of replicas

So pods use JVM modding techniques to fetch unique records from DB so that duplicate records are not processed by 2 pods.
Anything else?
am not sure if that sort of functionality is already present or possible with KEDA but i didn't find it so asking here. Is there any way i can extend kubernetes HPA functionality or KEDA to define custom scaling policies ?

Unfortunately that's not possible with KEDA and I don't think that this is something that's supported by HPA either (but you should double check that).
As a workaround, you can implement an operator, that will be watching the deployments and if the replica count changes, it could kill all relevant pods.

An alternative is triggering a Job to kill all pods with kubectl when the deployment is changing replica counts.
You can rely on the Kubernetes events for that.


Correct deprecated finders prior to 4.0 upgrade

Fixes #466 by re-writing the code to use new syntax.

👍


Remove references to deleted "feature-states.css" file

This pull request removes references to feature-states.css, which was recently deleted in commit https://github.com/kubernetes/website/commit/f8bd5568c781021593e054f81a48a0eb0c3e7ab5 as part of revising appearance of feature-state shortcode. The site is currently throwing error (details below), prompting this change.

// Error reported in browser's console:
GET https://kubernetes.io/css/feature-states.css net::ERR_ABORTED 404 (Not Found)

Preview Page (Above error not found in browser console logs)
/area web-development

Thanks @dipesh-rawat for this fix.
/lgtm


Multi GPU Inference (generate.py) is not successfully done

Hi, now I'm trying to run generate.py by 4 GPUs. For finetuning the model, a good command is written at #182. This command worked well on my environment. Then, inspired by it, I set this command :
WORLD_SIZE=4 CUDA_VISIBLE_DEVICES=0,1,2,3 torchrun --nproc_per_node=4 --master_port=1234 generate.py --load_8bit --base_model 'decapoda-research/llama-7b-hf' --lora_weights 'tloen/alpaca-lora-7b'
But cuda out of memory happened... How can I resolve this issue? Thank you in advance.

I solved by myself.
WORLD_SIZE=1 CUDA_VISIBLE_DEVICES=0,1,2,3 python generate.py --load_8bit --base_model 'decapoda-research/llama-7b-hf' --lora_weights 'tloen/alpaca-lora-7b'

Above command was OK for 7B model, but for 13B and 30B model, output was strange when put with --load_8bit .
When using a single GPU, python generate.py --load_8bit --base_model 'decapoda-research/llama-13b-hf' --lora_weights 'tloen/alpaca-lora-13b' outputs sentences successfully, but when with 4 A10 GPUs, WORLD_SIZE=1 CUDA_VISIBLE_DEVICES=0,1,2,3 python generate.py --load_8bit --base_model 'decapoda-research/llama-13b-hf' --lora_weights 'chansung/alpaca-lora-13b' outputs garbled characters like "□□□□□□□□□□□□□□□□□□□□□□□□□□".
Is there any way to compress model without error?

same here, inference with multi-gpus will return result like "\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x02"

same here, inference with multi-gpus will return result like "\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x02"

Fix this by using just 1 GPU.


Fixing issue for rhel-9.1 and rhel-9.2

This fix issue: https://github.com/ppc64le-cloud/pvsadm/issues/439 Of image conversion for rhel

/cc @sudeeshjohn @mkumatag


State Linux is the preferred dev platform in readme

I just went through a loop of trying to build on Windows (got errors), then WSL (got errors) and finally an Ubuntu VM (so far seems to work). Others also seemed to have had issues building on Windows (#1121).
Supposing most contributors build on Linux, this line in readme would've saved me a lot of time, googling and frustration.
Just an idea, feel free to decline.
Have a nice day.

@googlebot I signed it!

Sorry about the lack of windows support; I just got a windows laptop, so I'm hoping to finally resolve this dev hurdle. MacOS is fine; that's what I develop on. Did you close this because you got it working?

@elalish I closed this because WSL might actually be fine, I probably just had na outdated node or npm version on there and that caused errors.
The Windows build didn't work though and I don't know the cause. So I guess it's good to include the message for the time being.

Yes, I believe someone else also found that WSL had an out of date node version by default. Now that I have a windows machine to test on I'll try to get it working better and update the docs accordingly.


Largely rework the Object Tutorial

With the advent of is built all the common use-cases of object
construction are now covered by our attribute syntax. This means that the
need to fall back to using BUILD has lessened enormously. Given that
BUILD has a number of behaviours that are non-obvious and require
knowing and understanding them, it makes sense to consider BUILD the
last resort mechanism to use when all else fails and recommend using
automatic attribute initialization and TWEAK for everything else.
Communicating this clearly in our object tutorial is very valuable, it
shows newcomers the sane default first. We do not want to send them off in
the wrong direction as BUILD has proven to be a stumbling block for new
users numerous times.
(Probably not entirely complete) List of Changes:

Try to be more structured by reordering things.
Add more headings for easier navigation.
Explain is built.
Rework examples to not use BUILD anymore.
Remove wrong explanation of the Task example stating one would need a
BUILD when custom constructors are used.
Remove in-depth explanation of BUILD. Add respective documentation for
TWEAK. BUILD is still explained in detail in the Object Reference.
State that BUILD is only intended for advanced use-cases.
Remove Hero example which is made obsolete by is built.
Simplify the Str-with-ID example and remove bits promoting making
TWEAK a method instead of a submethod.
Remove confusing bit about my vs our class variables.
Rename Static Fields? heading to Class variables
Replace the Singleton example with the Str-with-ID example as that
shows the "variable shared by all instances" aspect better than a
singleton (of which there usually only is one).

I wonder what policy do we have about headers (I am sure there is none, though).
Such changes will break local anchors.
While not commenting on the content itself, I suppose other languages have their docs versioned to avoid this trouble completely, right? E.g. langfoo.com/docs/v1/foo#header will never change even if langfoo.co/docs/v1.1/foo will have no #header anchor.

Oh. I was totally unaware of that problem. I guess we need a strategy first to tackle that problem. Do you consider the header problem a blocker for this PR?

Re: versioning. The problem is that most languages release documentation and code in lockstep. That's not our case, simply because there's a large backlog; tooling does not allow that for the time being. @Altai-man 's proposal would definitely have that advantage, but then there would be other issues regarding the granularity of changes. Anyway, let's get to this specific PR.
In principle, large PRs are always a problem. There are many small issues, every one of which might or might not be a blocker; if there's some problem with one, the whole PR gets blocked. Also, they obviously need time to be reviewed properly.
But the second, and maybe major, issue, is the use of "we prefer" or "is obsolete". Unless blatantly incorrect, there's no good reason to totally hide a behavior, even more so when the text is probably there as the result of solving some issue, and definitely as the work of someone that's taken care of it. So in this case, and in general, I'm more for "build upon" than "rework", and insert something like "From 2021.01, it's considered a better practice..." TIMTOWDI and all that. That takes care of not eliminating headers, for instance, since it's only adding new headers what would be done.
That said, let me take a look at this to check if we can steer it into suggestions for better behavior instead of eliminating old ones.

@JJ Thanks for the detailed review! I'll try to work through it!
Independent of this specific PR I think we should talk about how to best approach changes to the documentation, because I think that we currently have different approaches. We should talk about that, so we don't keep annoying each other every time we do something together on the docs.
I think there are two topics:
Small vs large changes
When working on the documentation I often find it difficult to separate individual changes from one another. I think that's because free-form text is usually not as strictly structured and isolated than source code, so when working on a text it often happens that one change necessitates another (because texts are so interleaved). This has the effect, that when I do changes on a larger scale the text is at no point in the refactoring in a state where it is consistent and suitable for publication. I will try to aim for smaller changes and create more intermediate commits in the future. It probably makes sense to squash them before merging, as changes will probably not be atomic.
Removing content
I think there are situations where removing content is appropriate.

When content does not add any information that was not already explained in a more appropriate place.
It does not fit into the overall structure or narrative of the document
It is not easy to understand for the target audience of the document
Its text to information ratio is too low
It is factually wrong

In some cases it is possible and makes sense to improve the bit of content in question or move it to some other place where it fits in better. Other times that is not possible.
The topic of removing content is especially controversial with tutorials, as they need not be all-encompassing as a reference needs to be, but must balance multiple interests:

ease of understanding
provide enough of information to get the reader started in a topic
be narrated well
don't put too high requirements on the things the reader needs to know to understand the tutorial
"build up" of information (explain things before they are used)

I'd like to hear your opinion on this.

Oh. I was totally unaware of that problem. I guess we need a strategy first to tackle that problem. Do you consider the header problem a blocker for this PR?

No, not really. I mean, we did it for literally years and while there were concerns about preserving URLs, the general flow is a bit LTA to stick to it. I am just re-confirming for myself there is an issue in this area.

@JJ Thanks for the detailed review! I'll try to work through it!
Independent of this specific PR I think we should talk about how to best approach changes to the documentation, because I think that we currently have different approaches. We should talk about that, so we don't keep annoying each other every time we do something together on the docs.
I think there are two topics:
Small vs large changes
When working on the documentation I often find it difficult to separate individual changes from one another. I think that's because free-form text is usually not as strictly structured and isolated than source code, so when working on a text it often happens that one change necessitates another (because texts are so interleaved). This has the effect, that when I do changes on a larger scale the text is at no point in the refactoring in a state where it is consistent and suitable for publication. I will try to aim for smaller changes and create more intermediate commits in the future. It probably makes sense to squash them before merging, as changes will probably not be atomic.

That's probably a better approach, and it will allow everyone to pay more attention to them and review them properly.

Removing content
I think there are situations where removing content is appropriate.
* When content does not add any information that was not already explained in a more appropriate place.

In principle, we're no the same page here. Incorrect, repeated, confusing documentation should probably removed. But a PR is not the place for that: first the issue, then a PR for that specific problem. Removing code, moving it around in a PR together with different things means that blocking it for improvements will be throwing away the baby with the bath water. So again atomic, issue-related changes makes everything easier.

* It does not fit into the overall structure or narrative of the document

* It is not easy to understand for the target audience of the document

Again, these are issues that probably need to be raised independently of a PR, and previous to that. It might include headers, or anchors, or some things that we need to move elsewhere, probably.

* Its text to information ratio is too low

* It is factually wrong

No doubt is something is wrong it needs to be fixed. Removed, that's a different thing altogether.

In some cases it is possible and makes sense to improve the bit of content in question or move it to some other place where it fits in better. Other times that is not possible.

Yep, but discussing that in the context of the change itself does not leave a lot of room for maneuvering.

The topic of removing content is especially controversial with tutorials, as they need not be all-encompassing as a reference needs to be, but must balance multiple interests:
* ease of understanding

* provide enough of information to get the reader started in a topic

* be narrated well

But those are general principles for the documentation we can all agree on. But the problem is that we need to agree how that applies to the original piece of documentation it refers to. That's why I favor an incremental approach. First add the new thing, then check if there's something else it can replace.

I am reworking this. Thus I turned it into a draft.

Oh. I was totally unaware of that problem. I guess we need a strategy first to tackle that problem. Do you consider the header problem a blocker for this PR?

No, not really. I mean, we did it for literally years and while there were concerns about preserving URLs, the general flow is a bit LTA to stick to it. I am just re-confirming for myself there is an issue in this area.

I think that the 'header' issue is a part of a more general issue of what I suggest we call 'target consistency'. Namely the within a collection of content files, there are links to targets in other content files. Since all headers are by default targets (all current pod renderers automatically include an 'id' or 'name' attribute that can be a part of a <a href="..."> in another file), changing the name of a header will cause links in other files to fail.  But headers are not the only target creators, there are also X<> codes.
It is not cost beneificial to set up an infrastructure to keep track of target/link connections. However, it is possible to create tests that check links across the entire collections.
In this way, when a change in one file (editing a header) causes a link failure, the test will flag a link failure. I have implemented such a test with my Collection tool chain.  The implementation is not yet good because I have too many false positives.
But even tracking that down has led to some undocumented behaviours of Pod::To::HTML and the assumptions of early documentation writers.

In this way, when a change in one file (editing a header) causes a link failure, the test will flag a link failure

The issue I am concerned with is that not only one parts of the docs link other parts of the docs (and we control both, so surely can test and fix issues on our side), but that any third-party source like a blog post or a search engine or whatever can (and should) point to the doc pages which will become broken with the flow of time because people rewrite paragraphs, change headers etc. And we cannot test the whole Web and fix people's content.
In the world where Raku has a good documentation web resource, URLs must be set in stone forever and ever. The way to do it is to start real versioning: one has to call the current version, say, 1.0, and all the upward changes go into master/upstream/whatever prefix. Then one day this prefix is frozen into 1.1 and the cycle continues.
It is a schema everyone is using except us (because we lacked tooling back then and lack volunteers to do the heavy-lifting now).
Absence of this mechanism also leads to various ad-hoc solutions like "This and that was working since release 2018.11".
I think https://github.com/Raku/doc/issues/2690 kinda relates to this. The https://github.com/Altai-man/docs.raku.org/issues/6 was intended as a starting point for this, since it is not that hard to implement dynamic serving various versions with Cro, but no volunteers fancy.

Superseded by https://github.com/Raku/doc/pull/4047


Discard logs for hibernated and testing clusters

What would you like to be added:
Throw away logs for shoot-* namespace that have no elasticsearch running.
Why is this needed:
The fluentd-es is buffering pod logs from the whole seed cluster.
For shoot clusters that are hibernated or with spec.purpose=testing there is no pods backing the elasticsearch-logging service. However, fluentd is not aware of this and is trying to send logs there. The result is that fluentd-es is scaled to maximum employing all of its memory for the buffers.
Some options to mitigate this is:

Deploy a black hole pod instead of the elasticsearch that will accept the logs and write them in /dev/null.
Implement a golang output plugin [1] that has a notion about gardener and can drop logs for shoot clusters without elasticsearch.

[1] https://github.com/fluent/fluent-bit/blob/81deab2bb042c814cee964563c12e8bdd55d8af3/GOLANG_OUTPUT_PLUGIN.md
cc @donistz

Another options is to add fluentbit.io/exclude=true annotation in the pod templates for the hibernated shoots and those with purpose=testing. In this way fluentbit will drop logs from these pods.
FYI, there is a bug in fluentbit, the annotation is honored only for newly created pods - https://github.com/fluent/fluent-bit/issues/1142

I agree that ignoring testing purpose Shoots would be an improvement.
For the issue that @vlerenc and @rfranzke reported beginning of this week for the "hanged" logging in one of the Seeds - as far as I see there are no Shoots with testing purpose on that Seed. So probably the issue is another one?

We also had the TF pod issue, where it was triggered again and again. @vlvasilev opened #2253.
Together, i.e. this and the other issue, we may have identified two main suspects. However, there is no guarantee, but we can't have an infinitely scaling logging infrastructure either, so until we notice another issue, I hope these two issues bring us back our logs.
With Augustus: "Oh Varus, give me back my legions logs, please". I took the liberty to append the "please". ;-)
Since without logs, we are kind of screwed, can we please fix that rather sooner than later?
/priority/critical

Long time ago @rfranzke asked "why?" about https://github.com/gardener/gardener/pull/1924. Generally I want to write something about it:

It sucks the way new feature is merged into g/g. In the logging case it is 1 PR that introduce the feature and n following PR that fix (try to make usable) this feature.
https://github.com/gardener/gardener/pull/176 is merged with the following Easter eggs (@rfranzke, was that the right term?):

https://github.com/gardener/gardener/pull/616 (coredns producing huge amount of logs, was the logging tested/enabled at all before that?)
https://github.com/gardener/gardener/pull/681
https://github.com/gardener/gardener/pull/902 (that one was "interesting" one requiring "workarounds" in upstream plugin as fluentd was discarding logs of woken up Shoots because of hibernated ones (1 buffer queue is used and the whole queue was discarded when there is a failure because of hibernated Shoot))
https://github.com/gardener/gardener/pull/1017 (was even fluentd successfully scaled to 2-3 replicas before that as HPA and seed controller were all the time thrashing and setting replica count to 1 (seed-controller) and after that to n (HPA)?)
Probably there are more, I just don't want to dig further.

Generally because of the reasons above I (just nit spotter and typo fixer) personally have no more "logging fuel".

/close
as the issue should be fixed by #2320


⚠ Bofrost.lu has degraded performance

In 53c9296, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1578 ms

Resolved: Bofrost.lu performance has improved in 59c0e0c after 6 minutes.


feat: admin improvements (user list)

:tada: This PR is included in version 1.46.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Cherry pick ae22eed515a into dev

https://github.com/dart-lang/sdk/commit/ae22eed515a7855ee3bba3c031faab8332a5c0f4

Merged in 1.23.0-dev.11.4


Fix weirdness with image left/right on small screens

Image right looks a bit odd on mobile. Also, consider "before"/"after" as terminology instead of "left"/"right" due to responsive squash?

This is from markup, so we put image box first even if image box is on right to make it look good at mobile, but obviously this is not intuitive way of writing markdown, so there was mistake about it. fixing it now.


Cleanup lists of tests in ci.yaml

I deduplicated the list of platform-independent tests and sequestered it to an environment variable for reusability. I then sorted the resulting two lists (platform-independent and Windows-only) and took out duplicate entries of test_json and test_set.

Question for the maintainers: would you rather leave the lists as separate lines or fold those lines up into fewer lines?

Just so everyone knows once again the iphone 7 has been sold so any changes made last night other than on the iphone XS is false and another attempt on hacking my information and accounts . Also if any fx card or coinbase transactions or any transactions come across they are not mines. I have not recieved any progress because of these same issues since day one . Vedarius Russell of Youtac RS/ VARs


(feature): Automate monthly downloads and discord members on the homepage

Subject
Homepage
Description
The discord members and monthly downloads on the homepage are still hardcoded and need to be updated manually. Would be nice if that could be automated.

Hi @noobinthisgame, is this issue open for anyone?

Hi @ashalfarhan! Yes of course :) Feel free to have a go at it :)

I want to work on this, but I'm figuring how can I get the discord channel members, I've searched for the Discord API Docs, and it seems like to get the channel members I need to be authenticated first, and as I'm planning is to hit npm and Discord API, is that what this should be done?


Ability to complete Quiz with a single click.

A minor pull request, adds the functionality to dynamically end a quiz. This might help, for use case to end quiz after timer runs out.

Fixes #71


Some files have different licenser from LICENSE.

I found some files which has different licenser from LICENSE.
Could you fix it?
LICENSE says licenser is "Olivier Poitrey".
https://github.com/rs/SDWebImage/blob/master/LICENSE
but...
1.licenser is "Dailymotion".
below files.
SDWebImage/MKAnnotationView+WebCache.h
SDWebImage/MKAnnotationView+WebCache.m
SDWebImage/NSData+ImageContentType.h
SDWebImage/NSData+ImageContentType.m
SDWebImage/SDWebImageCompat.m
SDWebImage/UIImage+MultiFormat.h
SDWebImage/UIImage+MultiFormat.m
SDWebImage/UIImage+WebP.h
SDWebImage/UIImage+WebP.m
2.licenser is "MyCompanyName".
SDWebImage/UIImage+GIF.h
SDWebImage/UIImage+GIF.m
3.licenser is "Olivier Poitrey and Jamie Pinkham"
SDWebImage/SDWebImageCompat.h

Right. We need to review this.
@rs what should we use?


new lib

LazWebsockets. [FPC] This provides a small Websocket server and client implementation written for the FPC and Lazarus. It is fully based upon the fcl ssockets unit and therefore independent from any additional dependencies except from the FCL.
decTreeView. [Delphi] The decTreeView library is an alternative implementation of the TreeView (SysTreeView32) control
NetCom7. [Delphi] This set of components is the fastest possible implementation of socket communications, in any language; this is an extremely optimised code on TCP/IP sockets.
Keras4Delphi. [Delphi] Keras4Delphi is a high-level neural networks API, written in Pascal with Python Binding
dexif. [Delphi] [FPC] Lazarus port of Delphi EXIF Library to extract Exif Information from Images

Wow! Added, thanks!


use try{...}catch(e){...} can crash

Issue type:

:bug: Bug

Short description:

Steps to reproduce the problem:

use script:

function f1(itemStackElement,networkStackExpr) {
    try {
        for (const element of itemStackElement) {
            let operatorApply = idContext.ops.operatorApply(networkStackExpr, element);
            if (operatorApply < 512) {
                console.log(`Operator Apply: ${operatorApply}`);

                return operatorApply;
            }

        }
    }catch(e) {
        console.log(e);
    }
}

Expected behaviour:

Versions:

This mod: 1.0.7-146
Minecraft: 1.12.1
Mod loader version: neoforge - 21.1.57

Log file:

crash-2024-12-23_00.02.08-server.txt

Thanks for reporting!

Could you reproduce what you did to get this, in an environment with just Scripting installed (with dependencies)?
It looks like this might be a clear bug already but just in case.

crash-2024-12-23_12.49.29-server.txt
saves.zip
i directly use throw new Error().
The main reason for a crash is that no value is returned after catching an error


Added content mapper changes from develop

@wachterjohannes Can you have a deep look at these tests, to see if they really cover the bugfixes you made?

@danrot I am pretty sure these tests cover the bugs, as I encountered the bugs and fixed them for each case.

Merging now, as the test failure is already in develop due to the rebase.


Consider exemption to the "PII is hidden" message for configuration retrieval failures

Hi,
We recently encountered a situation where the http request to retrieve the OpenID discovery document was failing in production.  Our logs are showing the very not useful IDX20803: Unable to obtain configuration from: '[PII is hidden. For more details... message.  That completely hiding the real reason why the request failed.
  However, I don't see how  the lines that throw the IDX20803 could disclose Personally Identifiable Information.  There's not user here.
A proposition would be to not call LogHelper.FormatInvariant() on the Configuration retrieval if it fails.
Please educated me if there is a PII disclosure risk here.
PS: I guess that as an alternatively, I could turn off ShowPII just before the config retrieval and then turn in back on.  I would probably work but I don't feel everyone should have to do that.
Thanks

@oliviervaillancourt i agree with you. In our need to satisfy GDPR, we used a big hammer, we need to revisit this.
I marked this as an Enhancement.

@brentschmaltz .  Thanks for the update.  If you think that a simple change to remove the "PII masking" in the case of GetConfiguration  is appropriate, I don't mind doing that work and submitting a PR.
Thanks

@peval27 others have commented on this.
We will work to make some progress on this in July.
see: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/1427 where we wrote:
We recognize the need to adjust this for an application that is running.
We have these issues that address this:
#1274
#1452
If you would like us to consider these in next months release, please put a mark on those issues.

We're going to focus on #1274 so that it's easier to modify the value of ShowPII at runtime.

We're going to focus on #1274 so that it's easier to modify the value of ShowPII at runtime.


Variety of approaches is used for restricting actor for permission checking

In CountdownGriefingEscrow, the function depositPayment() checks using:
if (!isBuyer(msg.sender) && !Operated.isActiveOperator(msg.sender)) {
    require(_data.buyer == address(0), "only buyer or active operator");
...

And depositStake() does similarly.
These are equivalent to an alternate approach used for the rest of the code, for example finalize():
require(isBuyer(msg.sender) || Operated.isActiveOperator(msg.sender), "only buyer or active operator");

Using a variety of approaches to perform the same task reduces code readability.
Recommendation: update depositPayment() and ``depositStake()` to use the mechanism as per neighboring code.

completed


goimports fixer doesn't work for vendored libraries

In Go you can "vendor" packages by putting them in the vendor/
directory for a project. goimports picks up these packages, in
addition to what you have in GOPATH.
The goimports fixer works by copying the Go file to a temporary
directory (in e.g. /tmp/) and then running goimports on it. This
means that it won't see the vendored packages, since that is outside of
the project's directory.
To be useful, goimports should be run on the real file, and not a
temporary file.

:ALEFix can't modify any of your files. It needs to pipeline the buffer data from one fixer to another. Is there any way to run goimports on a temporary file and also tell it where the libraries are?

Cheers! :beers:


prt4cmd.exe fails to load com.esri.prt.unreal.dll

Hello,
While following the README_windows, for the command:
C:\cityengine-sdk\examples\prt4cmd\install>bin\prt4cmd.exe -l 3 -g ..\..\..\data\candler_footprint.obj -p ..\..\..\data\candler.rpk -a ruleFile:string=bin/candler.cgb -a startRule:string=Default$Footprint -e com.esri.prt.codecs.OBJEncoder -z baseName:string=theCandler

the following error occured :
[2022-11-10 13:51:11] [error] failed to load library: error while loading library 'C:\cityengine-sdk\examples\prt4cmd\install\lib\com.esri.prt.unreal.dll': The specified module could not be found.
[2022-11-10 13:51:11] [warning] Failed to load library 'C:\cityengine-sdk\examples\prt4cmd\install\lib\com.esri.prt.unreal.dll' as extension for PRT core at 'C:\cityengine-sdk\examples\prt4cmd\install\bin\com.esri.prt.core.dll'
[2022-11-10 13:51:11] [warning] CGB file contains warning 'Potentially problematic CGAC version 1.6 : recompiling with current CGA Compiler (1.19) is recommended.'

Removing com.esri.prt.unreal.dll in examples\prt4cmd\install\lib fixed the error. Note that I don't have Unreal Engine installed on my machine.
Thanks,
Olivier

Thanks for the feedback. We recognize that this error message is somewhat misleading. If you do not need the Unreal encoder for your task then this error can be ignored - or - you might want to install the Epic launcher which will install the necessary runtime dependencies for our Unreal encoder dll.

this error can be ignored, prt4cmd will still work correctly

Unfortunately it prevents prt4cmd from working correctly, this is why the dll must be removed in my case. This is somewhat hard to figure out for new users.

Ok, that is unexpected. We will look into it asap.

Actually, one more question: you are seeing that when the unreal encoder cannot be loaded, you will not get the expected OBJ file in the output folder, correct?

My bad, actually the tool produces results in case the dll failed to load.

Maybe this error message should be made a warning instead?

Also the "output" directory is actually inside the install directory, not next to the install directory contrary to what the doc says:

The result is placed in a new output directory next to the install directory

This adds to the confusion because when looking for this folder at the location the doc specifies, nothing is there.
Maybe a success message in the tool saying where the results have been written would be useful.

Maybe this error message should be made a warning instead?

Agreed - the error on the first line is actually the underlying issue, while the second line with the warning is the main message to the user. We'll try to demote the error to a warning as well (or merge the two).

Ah ok, makes sense.


MM-12810 Webapp redirecting to select_team page when base url is hit

Summary
Props change is used for redirecting to default team which causes a race condition. User info is loaded into state triggering a props change so redirectUserToDefaultTeam take user to select_team page if there is a delay in state change for user teams.
Ticket Link
(https://mattermost.atlassian.net/browse/MM-12810)[MM-12810]
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] Ran make check-style to check for style errors (required for all pull requests)
[x] Ran make test to ensure unit and component tests passed
[] Added or updated unit tests (required for all new features)

Got a style error then ready to merge:
home/ubuntu/jenkins/workspace/w_mattermost-webapp_PR-1945-TC6BVEWLJ4JKMBQQ4HBH5OTT4AX7HOVF6A76HK2AE2DWGY4MSQGQ/components/root/root.jsx
  21:8  error  'UserStore' is defined but never used  no-unused-vars
✖ 1 problem (1 error, 0 warnings)

Done. Fixed lint. Waiting to hear about milestone on this ticket


Broken in Chromium/Chrome

Problem
Chromium (Ubuntu 22.04) is not working anymore!
The palette is not synchronized from the IndexedDB, console logs:
tslib.es6.js:118 Uncaught (in promise) Invalid lex string
fulfilled @ tslib.es6.js:118
Promise.then (async)
step @ tslib.es6.js:120
fulfilled @ tslib.es6.js:118
Promise.then (async)
step @ tslib.es6.js:120
(anonymous) @ tslib.es6.js:121
__awaiter @ tslib.es6.js:117
synchronizePaletteFromDb @ palette.ts:298
ColorizerPalette @ palette.ts:122
ColorizerController @ controller.ts:30
(anonymous) @ colorizer.ts:10
Show 6 more frames

While testing in the local network with a (mobile) Chrome, adding colors is broken aswell (as that test was executed from my phone, no detailled error messages, might be the same issue).
Research

This SO thread suggests that the error is raised because of a missing catch() while dealing with promises.
this may be solved during #42 , as failures during database access should end up in a notification, so there will be catch() blocks anyway.

It's working, without real consideration...


Cant get any response with Scrapy+Splash but with Pure Scrapy I get response

I tried "ROBOTSTXT_OBEY = False", increasing timeout and "http://localhost:8050" but didn't work with Scrapy+Splash. Then I tried Pure Scrapy Request with same code and same settings and It worked. Pure Scarpy isn't enough itself for me. I need your help to understand why splash doesn't work with that website and how to fix it. The website Im talking about: https://www.asos.com/

Hi Kadenn,
First of all you need to disable private mode in Splash and assign a valid user agent to the request.
Here is the code is used:
function main(splash, args)
  splash.private_mode_enabled = false
  headers = {
    ['User-Agent'] = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36'
  }
  splash:set_custom_headers(headers)
  assert(splash:go(args.url))
  assert(splash:wait(0.5))
  return splash:png()
end

I tested it and did work perfectly fine on my side.
Make sure you return splash:html() instead of splash:png() so you can parse the response using Scrapy.
Kind regards,
Ahmed.

Hi Kadenn,
First of all you need to disable private mode in Splash and assign a valid user agent to the request.
Here is the code is used:
function main(splash, args)
  splash.private_mode_enabled = false
  headers = {
    ['User-Agent'] = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36'
  }
  splash:set_custom_headers(headers)
  assert(splash:go(args.url))
  assert(splash:wait(0.5))
  return splash:png()
end

I tested it and did work perfectly fine on my side.
Make sure you return splash:html() instead of splash:png() so you can parse the response using Scrapy.
Kind regards,
Ahmed.

First of all thank you for saving me from this toruble, It worked for me too. I was already chancing user agents  randomly and my private_mode set to FALSE while I was creating docker container. I don't understand why it is working when you set from script in spider but not working when I set from settings.py.


Add Favicon

Add the logo of ML-Fusion-Labs as a favicon to help visitors locate the page easily when they have multiple tabs open.

Kindly assign this issue to me so that I can start working on it.

Hi @Nandini-13, pls complete the issue that I have assigned now, then you can do this

@Nandini-13 , i believe i can solve this issue . please assign it me under . GSSoC24 Extd

@Nandini-13, is it okay for you, if i assign @riyarane46

@riyarane46,
till then you can look for other issues at website like improvements and create an new issue for that.

@vivekvardhan2810 I have implemented the necessary changes and made a pull request for issue #7 . Kindly assign issue #8 to me if the changes for the previous issue are upto the mark.


Infinite $digest loop when using angular 1.7.x with html5mode enabled

This issue tracker is for Bug Reports and Feature Requests only.
Please direct requests for help to StackOverflow.
See http://bit.ly/UIR-SOF for details.
This is a (check one box):

[x] Bug Report
[ ] Feature Request
[ ] General Query

My version of UI-Router is: (type version)
1.0.18 (latest)
Bug Report
Current Behavior:
$state.go('some_state', { param: "special character such as '" }
result in infinite $digest loop. Browser tab crashes.

Doesn't happen on angularjs 1.6.x
Expected Behavior:
Don't crash
Link to Plunker or stackblitz that reproduces the issue:
http://jsfiddle.net/3s4602e1/14/

Closed as a dup of https://github.com/angular/angular.js/issues/16592


revert inputhook param location

In https://github.com/ipython/ipython/pull/11979, a fix was made for ipdb however, the location of the param lookup was changed by accident? it is certainly breaking it for me.

I forked a fork...whoops.


Allow exceptions to window swallowing

As far as I can see, under the current implementation window swallowing is pretty much all or nothing - if I add the terminal in the regex, it will swallow any window it spawns. While that's the desired behaviour almost all the time there's occasionally some exceptions (like wev) where you want to keep the default behaviour. Could we add something like swallow_exception_regex for this use case?

how would you even except that to work?? Can't you just make a regex that does not target that one thing that you don't want to swallow?

I think swallow_regex =^(classes)$ but in reverse (not terminals but child windows like wev for example)

Most terminals put the working application on their title, or can be configured to do so, so what about excluding by title?
I'm not particularly good with regex yet, but I think it'd go something like: swallow_regex=class:kitty,title:^(?!wev)$

I think swallow_regex =^(classes)$ but in reverse (not terminals but child windows like wev for example)

Yes exactly, other WMs that do swallowing like DWM for instance already have this functionality. Implementation-wise it just boils down to matching against the regex before a window is about to be swallowed to see if it's one of the exceptions or not.
I implemented a PR that does just that, it's the one mentioned right above this comment. I tested it on my machine and now it works as intended.

why this open?

Good question, probably oversight.. I'll close this


Typo in autodetection doc

Fix typo in "Configure IP autodetection" doc.

Merge to nightly

Deploy preview for calico ready!
Built with commit 03c90f5ff4782f6f8d37ab7d86b0e9c5be46f4bf
https://deploy-preview-3329--calico.netlify.com


Hash results between release and debug build differs

I'm facing a strange issue. When I calculate the hash value of a binary blob with size 920603 in release and debug build I get different hash results.
I'm calculating the hash value with the following code:
let mut hasher = AHasher::default();
hasher.write(&data);
cksum = hasher.finish()

I'm using rustc 1.48.0-nightly (0e2c1281e 2020-09-07) on Windows. I couldn't test it yet with stable because my project depends on unstable features.

AHasher::default() is implemented via: AHasher::new_with_keys(const_random!(u128), const_random!(u128))
So every time you compile it you should get different keys, and hence different output values.
If you want different binaries to arrive at the same hash output, you have to specify the keys.
Be advised that aHash does not have a fixed standard for its algorithm, so if you compile two different versions of aHash or with different compiler/feature flags you will end up with different hash values even if you specify the keys.


Dash R Core Package Unification

This PR addresses plotly/dash-core#283 by introducing a gulpfile based script in the root directory of the dashr repo. This script sources from gulp-assets, which contains the main, updated, R export files from the respective core packages (dash-core-components, dash-html-components, and dash-table).
Running the npm unify command executes a series of tasks which incorporate the core package dependencies and NAMESPACE exports to the dash package, in preparation for a CRAN release. Running the npm clean command restores these dependencies so that the package can be used independently off of GIthub with the other core packages.

[x]  Fix DESCRIPTION to remove empty lines when running unify.
[x]  Run Rscript -e 'devtools::document()' to populate documentation help index.
[ ] Possibly remove all artifacts in gulp-assets to reduce package size until needed.
[ ] Open PR's in dcc and html to remove library imports from vignettes and examples.

Closes plotly/dash-core#283.

@ryan @alexcjohnson I think this PR should be in pretty good shape with these last few commits. CI tests are running successfully (thanks @rpkyle!) and I haven't encountered any obvious issues in running multiple test apps. There should be no more reference to imports of the component libraries, and I've added in some gulp tasks that should make updating those libraries within DashR in the future a relatively easier process. There's still a couple of minor things like writing up a CONTRIBUTING.md or at least an internal wiki on the update process, and opening PR's to scrub the dash-info.yaml in the other repos, but I think those can be addressed after merging this one.
I'd love to know if you have any final feedback before we can close this one out :slightly_smiling_face:

Looks like the example URL for htmlSource and htmlTrack has changed from
https://interactive-examples.mdn.mozilla.net/media/examples/friday.mp4

to
https://interactive-examples.mdn.mozilla.net/media/cc0-videos/friday.mp4

@HammadTheOne I went through the process of running the full Gulp workflow, assembled the unified package, and was able to run an application successfully -- but not without this favicon.ico error:
error: argument is of length zero
request: <IP_ADDRESS> - ID_<IP_ADDRESS> [18/May/2021:00:08:03 -0400] "GET /_favicon.ico HTTP/1.1" 500 0 "http://<IP_ADDRESS>:8050/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36"

I think this default favicon.ico tag was added in https://github.com/plotly/dashR/pull/240, to handle the case where a favicon.ico is not provided by an app. I see the one your PR added to inst, but I don't think it's loading here given the error above:
<link href="/_favicon.ico" rel="icon" type="image/x-icon">

We should fix this before we merge, I think.

@HammadTheOne I went through the process of running the full Gulp workflow, assembled the unified package, and was able to run an application successfully -- but not without this favicon.ico error:
error: argument is of length zero
request: <IP_ADDRESS> - ID_<IP_ADDRESS> [18/May/2021:00:08:03 -0400] "GET /_favicon.ico HTTP/1.1" 500 0 "http://<IP_ADDRESS>:8050/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36"

I think this default favicon.ico tag was added in #240, to handle the case where a favicon.ico is not provided by an app. I see the one your PR added to inst, but I don't think it's loading here given the error above:
<link href="/_favicon.ico" rel="icon" type="image/x-icon">

We should fix this before we merge, I think (assuming you can reproduce this also).

Thanks for catching that :bug: - based on our discussion, this is now fixed in ec1ab35.


Can't build on Ubuntu 20.04.2 LTS for some reason

I've installed the 2 dependencies:

Building and running xcolor requires xcb and Xlib libraries to be present.

$ sudo apt-get install libx11-dev libx11-xcb-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libx11-dev is already the newest version (2:1.6.9-2ubuntu1.2).
libx11-xcb-dev is already the newest version (2:1.6.9-2ubuntu1.2).
0 upgraded, 0 newly installed, 0 to remove and 65 not upgraded.

And this is the error I get when I try to install xcolor:
$ cargo install xcolor                                                                                Updating crates.io index
  Installing xcolor v0.5.1
   Compiling libc v0.2.103
   Compiling bitflags v1.2.1
   Compiling autocfg v1.0.1
   Compiling pkg-config v0.3.20
   Compiling unicode-width v0.1.9
   Compiling memchr v2.4.1
   Compiling strsim v0.8.0
   Compiling vec_map v0.8.2
   Compiling ansi_term v0.11.0
   Compiling cfg-if v1.0.0
   Compiling log v0.4.14
   Compiling version_check v0.9.3
   Compiling anyhow v1.0.44
   Compiling minimal-lexical v0.1.4
   Compiling lazy_static v1.4.0
   Compiling memoffset v0.6.4
   Compiling textwrap v0.11.0
   Compiling x11 v2.19.1
   Compiling nom v7.0.0
error: failed to run custom build command for `x11 v2.19.1`

Caused by:
  process didn't exit successfully: `/tmp/cargo-installMZTK9K/release/build/x11-fe4f423cee939653/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=X11_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=X11_STATIC
  cargo:rerun-if-env-changed=X11_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Command { command: "\"pkg-config\" \"--libs\" \"--cflags\" \"x11\" \"x11 >= <IP_ADDRESS>\"", cause: Os { code: 2, kind: NotFound, message: "No such file or directory" } }', /home/vagrant/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-2.19.1/build.rs:40:14
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `xcolor v0.5.1`, intermediate artifacts can be found at `/tmp/cargo-installMZTK9K`

Caused by:
  build failed

Any ideas?

It seems the dependency list in the readme might be somewhat incomplete. In additon to libx11-dev and libx11-xcb-dev you will also likely need libxcursor-dev. In addition you will need pkg-config and python3 as compile-time dependencies. I think the error you are seeing is about missing pkg-config.