Fix column_constraint parser rule for accepting empty column list

Description
SQL Server DDL definition accepts the following pattern:
REFERENCES referenced_table_name [ ( ref_column ) ]

There is a related babelfish_extensions' issue  and it has a pending PR.
Proposed patch:
diff --git a/src/main/parser/TSQLParser.g4 b/src/main/parser/TSQLParser.g4
index b2fa036..741e06b 100644
--- a/src/main/parser/TSQLParser.g4
+++ b/src/main/parser/TSQLParser.g4
@@ -3225,7 +3225,7 @@ column_constraint
     :(CONSTRAINT constraint=id)?
       ((PRIMARY KEY | UNIQUE) clustered? with_index_options?
       | CHECK for_replication? LR_BRACKET search_condition RR_BRACKET
-      | (FOREIGN KEY)? REFERENCES table_name LR_BRACKET pk = column_name_list RR_BRACKET (on_update | on_delete)*  for_replication?
+      | (FOREIGN KEY)? REFERENCES table_name (LR_BRACKET pk = column_name_list RR_BRACKET)? (on_update | on_delete)*  for_replication?
       | DEFAULT expression
       | null_notnull
       | WITH VALUES

@nasbyj -- could you grant me access to submit PRs and Issue Management?

This fix is already scheduled to be included for the next release of Compass


log: Context should accept an interface{} instead of a string

The Context interface and related methods should accept an interface{} over a string.
type Context interface {
	Context() map[string]string // -> map[string]interface{}
}

since writeValue will be called by go-kit/log to properly encode the string.

Do we want this sill? The latest release has map[string]string
https://github.com/moov-io/base/blob/v0.14.0/log/logger.go#L19-L20

@adamdecaf Yes, this would be a useful change.


Changing screen densities does not update LocalDensity or cause recomposition

Compose 1.0.0-beta5, MacOS Monterey, JDK11
When moving the application window between two monitors of different densities the LocalDensity does not update appropriately and the UI does not scale properly. This was working in alpha.
In the video below, the density is initially 2.0 and should change to 1.0 when the application is moved to the screen, but it stays at 2.0. The UI does not scale appropriately for the 1.0 density and all UI elements' size are doubled.
https://user-images.githubusercontent.com/6433145/141177350-326eb1ca-a9d1-4440-ad9e-3caf5fbf0a36.mov

Probably will be fixed in the next build (https://github.com/JetBrains/androidx/pull/71)

I can confirm that this has been fixed as of beta6-dev455

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


📎 Regenerate Algoria API key to use Biome document as index

Description
Currently when we search something on https://biomejs.dev , the search results links are https://rome.tools .
I think here needs change: https://github.com/biomejs/biome/blob/3a3cded8f1b1e9b4abbc11db7a8a4d056c7dad4f/website/src/frontend-scripts/docsearch.ts#L16

I was thinking that we could rewrite the website by using starlight, which uses https://pagefind.app/
I don't think we need algolia

OK, That's cool! I close this for now.


mobile app error after upgrade

Home Assistant release with the issue:
Home Assistant 0.103.2
Last working Home Assistant release (if known):
Home Assistant 0.103.1
Operating environment (Hass.io/Docker/Windows/etc.):
Docker (debian)
Integration:
Mobile app android 1.3.0 (50)
Description of problem:
errors reqarding android app in log:
Received invalid webhook payload: extra keys not allowed @ data['app_id']. Got 'io.homeassistant.companion.android'
extra keys not allowed @ data['app_name']. Got 'Home Assistant'
extra keys not allowed @ data['os_name']. Got 'Android'
extra keys not allowed @ data['supports_encryption']. Got False
Additional information:

sorry fixed with with app version 1.3.1(57)


feat(component): Select component

Adding select component to forms section.

@cogor, Do you like this implementation? I am planning to work on other components also.

Hi, I need some time for check this PR, you can take another component
P.S. Thanks for your work

LGTM


Make it possible to enable CSP in debug mode

I'd like to have this plugin enabled during development to not only spot possible breakage through CSP issues in production. But currently setting 'debug' => true always disables it.
I have two ideas how to solve this:

Instead of directly checking for the value of debug it could be used to set the default for enable. But this would change the behavior for people already using the plugin. :cry:
Make the debug option configurable just like enabled as  bnomei.securityheaders.debug so it can have a different value than the global debug option.

As a temporary workaround I use this code/configuration for my dev setup:
return [
    'debug' => true,
    /**
     * Weird workaround to enable the plugin even if debug is true
     * Works like this:
     * 1. Set enabled to false to skip the plugin instantiating the singleton
     * 2. Instantiate it on our own but forcing debug to false and enabled to true
     * 3. Profit
     */
    'bnomei.securityheaders.enabled' => false,
    'hooks' => [
        'route:before' => function (): void {
            \Bnomei\SecurityHeaders::singleton([
                'debug' => false,
                'enabled' => true,
            ])->sendHeaders();
        },
    ],
];

@kraftner thanks for the feeback. in most of my plugins i follow a rule like this "if the plugin does something that is not needed 100% then disable it in debug mode – debug is not production" (like caches or other optimizations). this is based on my own preference to have debug OFF in local development until i encounter a crash, then turning it ON until i fix the issue. so for me having debug enabled is a rare case. but i understand that this might not be how others see it.
so apart from how to setup local dev config files why exactly do you need debug and the cps enabled at the same time?

I can totally understand that having debug enabled is a matter of taste, but since tastes obviously differ I was just hoping to make this plugin flexible enough to have it easily cater to all. :)
Personally I have two main reasons:

While developing it is comfortable to have whoops tell me what exactly went wrong, including telling me about warnings.
I can have things (like e.g. switching API access to dummy endpoints or more detailed logging) all together tied to the debug state

i added a new value 'force'.
return [
    'debug' => true,
    'bnomei.securityheaders.enabled' => 'force',
    // other options...
];

Sorry to revive a dead horse, but when debug is ON, everything is fine; however, turning debug mode OFF, it tells me there's an error and in order to see it, I should turn it ON again :face_with_head_bandage:


Invalid syntax error

When I execute the example code gw2pvo --gw-station-id GWID --pvo-system-id PVOID --pvo-api-key KEY --log debug or anything for that matter, I get a Invalid syntax error.

I'm using python 3.6 on windows 10.
Thanks!

I think you have to fill in the GWID and PVOID for the actual parameters. Check out the Example section n the README.


E-Com website

Project-Guidance! 🎊🎈
Welcome! 🎉
Thank you for visiting our repository! We're excited to have you here. If you find this project useful, please consider giving it a star! ⭐
🎉 Have you reviewed the Contributing Guidelines? 🤔 (Required)

[ ] YES
[ ] NO

📝 Description

🔧 Fixes #issue_no (Required)

🏷 Initiative Participation (Required)
This pull request is associated with the following initiative. Please choose the one you are contributing to:

[ ] 🌸 GSSoC (Girl Script Summer of Code)
[ ] 🌼 GSSoC 2024 Extd.
[ ] 🍂 Hacktoberfest 2024
[ ] ❄ Script Winter of Code (SWoC)
[ ] ⛄ Winter of Blockchain (WoB)
[ ] 🙋♂ Personal
[ ] 📌 Other (please specify): _______________

I am the mentor of this project.
@adiiiii13 Hello
Kindly open issue first , if i'm satisfy then open pull request and can you describe about which e commerce website you talking?


fix: one-pager decomp labels and warning

Checking with CRAN if this one can land ASAP.

package Robyn_3.11.1.tar.gz is on its way to CRAN.


Support partitioning properties for Gemfire binder

Using these as a starting point, support the standard binder partitioning properties:
https://github.com/spring-cloud/spring-cloud-stream/blob/master/spring-cloud-stream-binders/spring-cloud-stream-binder-spi/src/main/java/org/springframework/cloud/stream/binder/BinderProperties.java#L69
https://github.com/spring-cloud/spring-cloud-stream/blob/master/spring-cloud-stream-binders/spring-cloud-stream-binder-spi/src/main/java/org/springframework/cloud/stream/binder/MessageChannelBinderSupport.java#L663

Closed in favor of https://github.com/spring-cloud/spring-cloud-stream-binder-gemfire/issues/2


Adding tests

Also, we should provide termination (with fail) by timeout for distillation tests. Whilst the ideal distiller must terminate on all inputs, some bugs lead to infinite calculations.
I hope, we can use this for interruption on timeout.


temporarily use custom repo

How do you think we should handle upstream packages that have been updated but not pushed.
For example, my patch to snakemake fixing relative paths with wrappers has been merged into upstream, but Johannes has not packaged a new version (3.10.1). In my patch I implement using urllib's way of dealing with relative paths, I updated the wrappers, but the tests will fail because the change is no backwards compatible.
I am sure this is a common problem with a few possible solutions.

ping Johannes and ask him to release a new version with the current master
package dev and push to our lcdb conda channel
patch travis to install from master
wait

Do you have a prefer/suggested method? I think I would lean towards pushing a dev package to the lcdb conda channel.  Don't really want to bug Johannes because he is busy enough and patching the travis code seem error prone.

Agreed, dev package to lcdblib is probably best. I would make the version numbers reflect this, e.g., https://www.python.org/dev/peps/pep-0440/#id35, so that we can keep both bioconda and lcdblib channels activated and not get confused about which channel the dependency is coming from.

Yep I think this is the best option.


Add a new allow-list.xml to gradle folder

Adding a new allow-list.xml that will work with the gradle cve-scanning action

Hey @josspo - you don't need to create 1 PR for each change.
If you commit gradle/allow-list.xml in your https://github.com/finos/security-scanning/tree/josspo-gradle-cve-scanning branch, the other PR will update automatically.


115 Illegal instruction

The anythingllm is installed in  Ubuntu server.
In the system LLM set ,the system can connect to the Ollama server and get the models .
But when chat in workspace ,the docker is exited.
1.Show the info in browser:

2.and the docker logs:
"/usr/local/bin/docker-entrypoint.sh: line 7:   115 Illegal instruction     (core dumped) node /app/server/index.js"
What's the problem?

Docker engine - it appears
https://github.com/Mintplex-Labs/anything-llm/issues/1290#issuecomment-2101960232
That issue is specifically occurring on Mac, but it is the same on Linux/Ubuntu as well.

Hi @lishaojun616 , have you managed to resolve the issue?
I am experiencing the same situation as you described in #1323 .

Hello everyone,
I face the same problem.
Same setup, ubuntu 22.04 LTS, using ollama as llm.
I have installed the newest docker engine, build anything-llm with docker-compose-v2.
...
[TELEMETRY SENT] {
  event: 'workspace_created',
  distinctId: 'c060354a-b171-4702-b83a-9da2ef0612e4',
  properties: {
    multiUserMode: false,
    LLMSelection: 'ollama',
    Embedder: 'native',
    VectorDbSelection: 'lancedb',
    runtime: 'docker'
  }
}
[Event Logged] - workspace_created
[TELEMETRY SENT] {
  event: 'onboarding_complete',
  distinctId: 'c060354a-b171-4702-b83a-9da2ef0612e4',
  properties: { runtime: 'docker' }
}
[NativeEmbedder] Initialized
/usr/local/bin/docker-entrypoint.sh: line 7:   119 Illegal instruction     (core dumped) node /app/server/index.js
gitlab-runner@gradio:~$ docker --version
Docker version 26.1.3, build b72abbb

This issue is marked as closed. Is there a solution available?
Best regrads
Joachim

Hi Timothy,
I think what @xsn-cloud and I have in commun is that we both use ollama.
May that ne the cause of the failure?
Joachim

@timothycarambat Thanks for addressing this issue. Please let me know if there's anything I can assist you with.
I've conducted the following experiment, also considering that it might be an issue with Docker running on VMs and to verify resource issues:

Clean install of Debian 12 on baremetal - Dual  Xeon E5-2650 v2 @ 2.60GHz with 96GB of RAM
Docker version 26.1.3, build b72abbb
Followed the procedure exactly as you did in  your previous comment (the same one you used on an Ubuntu 22.04 LTS AWS)
No documents loaded
During the onboarding, anything-llm successfully communicates with ollama, accurately retrieves the installed models, and allows the selection of the model without issues.

This is the outcome after the onboarding when attempting to send a "hello" in a new chat. (docker logs -f [containerid]).
Please note that the container was restarted from scratch to ensure the clarity of the logs.
Collector hot directory and tmp storage wiped!
Document processor app listening on port 8888
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma

✔ Generated Prisma Client (v5.3.1) to ./node_modules/@prisma/client in 338ms

Start using Prisma Client in Node.js (See: https://pris.ly/d/client)

'''
import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()
'''

or start using Prisma Client at the edge (See: https://pris.ly/d/accelerate)
'''
import { PrismaClient } from '@prisma/client/edge'
const prisma = new PrismaClient()
'''

See other ways of importing Prisma Client: http://pris.ly/d/importing-client

Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": SQLite database "anythingllm.db" at "file:../storage/anythingllm.db"

20 migrations found in prisma/migrations

No pending migrations to apply.
┌─────────────────────────────────────────────────────────┐
│  Update available 5.3.1 -> 5.14.0                       │
│  Run the following to update                            │
│    npm i --save-dev prisma@latest                       │
│    npm i @prisma/client@latest                          │
└─────────────────────────────────────────────────────────┘
[TELEMETRY ENABLED] Anonymous Telemetry enabled. Telemetry helps Mintplex Labs Inc improve AnythingLLM.
prisma:info Starting a sqlite pool with 33 connections.
fatal: not a git repository (or any of the parent directories): .git
getGitVersion Command failed: git rev-parse HEAD
fatal: not a git repository (or any of the parent directories): .git

[TELEMETRY SENT] {
  event: 'server_boot',
  distinctId: '4f39e3fb-ac8c-4043-9586-c21ef46b0c47',
  properties: { commit: '--', runtime: 'docker' }
}
[CommunicationKey] RSA key pair generated for signed payloads within AnythingLLM services.
Primary server in HTTP mode listening on port 3001
[NativeEmbedder] Initialized
/usr/local/bin/docker-entrypoint.sh: line 7:   163 Illegal instruction     (core dumped) node /app/server/index.js

Thanks a lot for your time.

If you were to not use the native embedder, this problem would not surface. The only commonality between all of this is varying CPUs. Transformers.js which runs the native embedder, uses ONNX runtime and at this point the root cause has to be coming from there as this only occurs when using the native embedder and that is the supporting libraries to enable that functionality.

Does the CPU you swapped to support AVXv2?

No, my CPU does not support AVX2 however it supports AVX

Does the CPU you swapped to support AVXv2?

I am sorry, i do not know how to check that, i just changed o "host" being a Intel Core i9-9900K CPU

At this time, the working hypothesis is that since Transformers.js uses ONNX runtime it will fail to execute any model (including the built in embedder) if AVX2 is not supported
https://github.com/microsoft/onnxruntime
@jorgen-k https://www.intel.com/content/www/us/en/products/sku/186605/intel-core-i99900k-processor-16m-cache-up-to-5-00-ghz/specifications.html

Instruction Set Extensions Intel® SSE4.1, Intel® SSE4.2, Intel® AVX2

Supports AVX2

I am using kvm as hyperviser and the virtual cpu doesn't support avx2. When I configure a passthrough of the cpu (which supports avx2)  as @jorgen-k has suggested it works for me as well.

I ran out of luck for the AVX cpu. It's a XEON 2660 but only supports AVX. Had to find another machine.

I had the same issue with "/usr/local/bin/docker-entrypoint.sh: line 7: 115 Illegal instruction (core dumped) node /app/server/index.js". It seems the new Docker images of AnythingLLM have some issues, possibly on older systems. To fix the issue, I tried using older Docker versions and previous AnythingLLM images. While the older Docker versions did not resolve the issue, the older AnythingLLM images worked great. The newest working version for me was "sha256:1d994f027b5519d4bc5e1299892e7d0be1405308f10d0350ecefc8e717d3154f". You can find it here: https://github.com/Mintplex-Labs/anything-llm/pkgs/container/anything-llm/209298508

@Smocvin, excellent work. Okay, then that pretty much nails down commit ca63012c0f569ad775b6fd22b9b7965d61812d77 as the issue commit. In that commit we moved from lancedb 0.1.19 to 0.4.11 (which is what we use on desktop version).
However, given how this issue seems to only be a problem with certain CPUs we have two choices:
Bump to 0.5.0 and see if that fixes it or roll back to 0.1.19. Given how we do not leverage or dive deep into LanceDBs API much, the code change is quite minimal or none.
What I will need though is some help from the community as I do not have a single machine, VM, or instance that I can replicate this bug with. So my ask is:

If you are getting this bug, and it is on a Cloud-container service. What service and instance specs are you using so we can provision a test instance for replicate and debugging.

or
If anyone is willing to help debug the hard way I am going to creat two new tags on docker :lancedb_bump :lancedb_revert and I would need someone suffering from this issue to pull both and see which works.
Obviously if we can bump up, that would be ideal, but I would rather not field this issue for the rest of time since lancedb should just work.
Links to images
lancedb_bump: TBD
lancedb_revert: TBD
Will update this comment when those images exist.

I'm happy to help debug here locally with the newly created image tags when available.   I have two machines I can test on here with AVX (Debian docker) and AVX2 (Windows docker desktop).   I get the core dump on the AVX machine with :latest but the AVX2 machine runs the container fine so I can provide output from both of them if needed.

@Dozer316 @acote88 @computersrmyfriends can any of you who have this issue on the master/latest image check and see if lancedb_bump or lancedb_revert work on the impact machine?
Hopefully the _bump image works, otherwise we are in for some pain, but at least we can debug from there. I am friends with the LanceDB team so I can escalate to them if the issue persists.

Hey there - revert has solved the problem on the impacted machine, bump still core dumps unfortunately.
Thanks for taking a look at this for us.

lancedb_bump: Crashes
lancedb_db: Works
CPU: AVX only
Using an external embedder (ollama also)

Thank you @Dozer316 @acote88 @xsn-cloud for all taking the time to test both, which is very tedious. Ill contact the lancedb team as well as see if we can rollback the docker vectordb package in the interim.

I just closed my report out #1618 because it was caused by the same thing. AVX was not a flag on the virtual CPU.

Okay, so the reason this issue occurs is due to LanceDB having its minimum target of haswell as of version ~0.20. This is because performance on AVX2 is just much better and haswell/AVX is really old.
So right now there are two options to go around this:

Upgrade or migrate use to a CPU that supports AVX2
We can maintain an image that works with the older vectordb package. Truthfully, I really dont want to do that and we have to draw the line somewhere. The reason I don't is that while code-change is minor this likely will become increasingly burdensome to maintain as we continue to bump lance into later versions. Knowing where the issue lies though is very useful.

Either way, the root cause is the requirement of the underlying CPU to have AVX2. Closing currently as wontfix but discussion is still open for any more commentary.

You have no idea how long I've had to search everywhere and how many reconfigurations and reinstalls I did before I found this thread. Could you MAYBE write SOMEWHERE that currently AnythingLLM requires an AVX2 CPU to work properly?

Hello @timothycarambat
Thank you for publishing the Lancedb_revert image at all in the first place.
Currently, googling the error message took me to this thread , which in turn links to this one.
To resolve the issue all I had to do was update the docker run command with the lancedb_revert tag, and otherwise "off it went"
My pc is old, but it's what I've got and sadly upgrading just isn't on the cards any time soon - I'm grateful to have a way to try it out at all.
I appreciate it's unreasonable to put in ongoing effort for small subset of users running into incompatibility problems because they insist on using a relic from the before times - Especially since it's going to start increasingly cropping up elsewhere as well.
Having an image an in the first place is great, but it'd be nice if there was some way to "run out the clock" on updates until breaking changes inevitably came along.
Would it be possible to have an unsupported update that pins the version of lancedb in place, dumps latest and/or dev over the top of it and "When it breaks, that's the end of the ride.... May the odds be ever in your favour"?
When it does, ideally the docker image gets a 2nd "unsupported final build" release based on that point version and that's the end of that.


Update spec to say what the default state / events defaults are

From inspecting the behaviour of synapse (which I'm not sure was intentional).
Are we sure this is necessary? I thought we always sent a power_levels event at room creation time with synapse, so in practice, no rooms will actually be affected?

Are we sure this is necessary? I thought we always sent a power_levels event at room creation time with synapse, so in practice, no rooms will actually be affected?

We do need to document this in the cases where there are no power level events, but yeah, in general synapse will always set them at creation time.

If it matches what's in synapse, LGTM

@Kegsay - could you second-review this?

All I can say is that having two different default state_defaults is horrible. Can we really not retrospectively make the default default default 50? What is going to be affected by this in practice?

I concur with the horrible-ness of two different state_default values depending on if the m.room.power_levels event is present vs present with the key missing. This smells like a bug in Synapse which should be fixed, rather than baking this behaviour into the spec. Given:

in general synapse will always set them at creation time

I would be happy to do a cursory sanity check to see which rooms will be affected on matrix.org (I suspect none?) and then actually fix this. I'm not happy to LGTM this in its current form.

OK, good. Leaving this open so it doesn't get lost.

Personally I'm becoming more inclined to say this is something that can be fixed in auth-events v2, but @Kegsay , will leave it it up to you.

I'd really prefer if we didn't spec this. We expect the number of rooms which will be affected by fixing Synapse to be low if not 0 (since it shouldn't happen due to m.room.power_levels always being set on room creation). I would prefer it if we just fixed Synapse and put something in the changelog along with the associated rationale. I don't like the precedent this sets otherwise (that bugs in Synapse will affect what is in the Spec).

This is not a bug. The fact that it probably wasn't an intentional decision, and is one that we don't like, doesn't change the fact that this isn't a bug. This is now part of the core API, and thus changing it is technically a breaking change that would require a major version bump (if we versioned the core API).
Now, if you can show that no rooms on matrix.org are relying on the current behaviour then I'd be amenable to waving our hands in the air and changing the behaviour.
However, I have a suspicion that this may very well affect every room. In particular, the authorization of the first m.room.power_levels may depend on the fact that the effective state_default is 0 at that point.
I'd also like to reiterate that there are a surprisingly large number of home servers in the wild, some on old versions, and thus changing the core API is something that needs to be done with an extraordinary amount of care to ensure we don't screw over those servers.
@Kegsay

I don't like the precedent this sets otherwise (that bugs in Synapse will affect what is in the Spec).

This is a valid concern, but:

Historically the authorization rules for events was defined by Synapse, and thus what Synapse does is by definition correct. I agree this is a suboptimal situation, but is nonetheless the situation we are in.
I believe the spec should specify what the current APIs are, warts and all. If we want to change those APIs then we should go through the appropriate process.

So, I'd really like to unblock this so that https://github.com/matrix-org/matrix-js-sdk/pull/94 can land (which in turn blocks about 5 other bugs).
@erikjohnston - does the m.room.power_levels auth actually depend on the implicit state_default power level being 0?  If so, you have a case - if not, i very much agree with @kegsay that we should fix up the spec to be correct and fix the reference implementation to match, rather than being coerced into aligning the spec to the broken behaviour we accidentally released into the wild.

So, I'd really like to unblock this so that matrix-org/matrix-js-sdk#94 can land (which in turn blocks about 5 other bugs).

I don't see why this is blocking that PR? If we do decide to change the behaviour, a) it won't instantly happen and get deployed everywhere, so you probably don't want to wait anyway, and b) we can change the default in the JS SDK later if we choose to change this.
If people's argument in favour of change is that this effects nobody, then what's the problem?

@erikjohnston - does the m.room.power_levels auth actually depend on the implicit state_default power level being 0? If so, you have a case - if not, i very much agree with @kegsay that we should fix up the spec to be correct and fix the reference implementation to match, rather than being coerced into aligning the spec to the broken behaviour we accidentally released into the wild.

(The following is written on the assumption it affects no one, but is equally valid as a general point regarding changes to federation)
This is my point, the spec as it is in this PR is, in my view, correct. Its the rules that servers are using. As far as I'm aware its not causing an issue anywhere, so I don't really see how its broken, or a bug, or an issue. You may not like, you may think we should change it, but it is correct. Yes, its a counter intuitive bit of the spec, yes it should be changed when we get to next changing the auth rules, but "its horrible" seems to be the sole argument for changing it.
I'd rather we just spec what we have today, so tomorrow we can see where all the "horrible" bits are and change them in the usual (and safe) fashion of bumping API versions when backwards incompatible changes are made. (And I'm generally in favour of spec'ing what we have now - even if we immediately change it - so that have a spec of how it did work, rather than a spec of how we wished it had worked)
Not changing this now does not mean we can't change this later. I am all in favour of changing this later. We just need a way of changing the auth rules in a safe fashion.
My concern is that we have played really quite fast and loose with changes to the auth rules in the past, but we absolutely need to get away from doing that now we're seeing increasing numbers of home servers. We have no way of knowing if this change will actually affect anyone, the best we can do is say that it won't effect anyone on matrix.org.
If this was actually causing a problem then I would be more inclined to say that we can take the risk of changing it, since the percentage of people effected by it would seem to be so low. But it is not causing an issue.
If we change it and it turns out to effect people, then a) we will need to justify why we changed it, and i don't believe that "it was a bit icky and no one on matrix.org was effected" is an acceptable answer and b) the failure mode of this would be bifurcated rooms which would be hell to debug for anyone not familiar with this PR (and even for those that are), and cause mass confusion to the users in the room as it will silently bifurcate with no indication in the UI that that has happened.
In summary:

Arguments for: This is a bit horrible, we don't like it, lets change it. Since nothing relies on the difference then it doesn't matter if we change it.

Arguments against: Why the hurry? This is already deployed to a large number of servers. This is not causing an actual issue. Changing it has non-zero risk of complicated breakages to peoples rooms, without the users in the room being aware that things are broken. We can, and should, change it later (in a safer manner).

We agreed on the offsite to spec what is rather than what should have been, so this is a valid change.


Consecutive hysteresis

Adds https://github.com/microsoft/DeepSpeed/pull/3553 to DeeperSpeed until it's merged upstream

oops wrong repo :(


Wing with a winglet

Dear @peterdsharpe,
I am planning on using your library to finish some assignments for an aerodynamical course.
Do you reckon it would be possible to simulate a wing with a winglet, to compute it's induced drag?
If the code does not support it yet, would you have an idea on how to do it, so I can implement it, use it and then merge it to your master branch?
Thank you.

Yes, it's absolutely possible to already model a winglet with AeroSandbox!
I'd recommend using AeroSandbox v0.3.0 for this instead of AeroSandbox v1.0.0-beta, as the latter is still under heavy modification (hence the beta suffix).
To use v0.3.0, you have two options:

Install v1.0.0 by using pip install aerosandbox at terminal. Then, import legacy AeroSandbox into python using import aerosandbox_legacy_v0 as asb, and use the definitions there. (Documentation in the associated files.
Install v0.3.0 directly by using pip install aerosandbox==0.3.0 at terminal. Then, import normally: import aerosandbox as asb.

Both should be identical - please let me know if you run into problems with either!
To model a winglet, you'll want to just add a wing section that bends the wing upwards as desired - easy as that!

And please keep me posted if you have issues - more than happy to help as time allows!

Awesome!
I'll keep you updated then.
To get my feet wet, I'll probably follow option number 2, but I'll then check I get the same results with option number 1, to ensure the transition took place correctly.

Closing this issue for now, but please open a new one or reopen this if you run into any issues!

Hello @peterdsharpe,
I hope you are doing well within the current coronavirus situation.
Reading through the issues of the repo, I have ruined into #17 , which mentions problems with moment estimations.
I need to get the wing root bending moment for my calculations, so I should change those lines of code mentioned in the issue, right?
Thx!

Hi @KikeM ,
Thank you, you too! Things are crazy here in the United States - last week I was evacuated from my usual workplace at MIT due to the pandemic, and I'm now staying with family in Missouri. It looks like you're in Spain, yes? (Spain will always have a special place in my heart - many years ago I used to live in Salamanca.) Good luck and stay safe out there - we'll all get through this together!
Yes, it's probably a good idea to change the lines of code mentioned in #17! However, the moments we were discussing in #17 refer to overall moments on the airplane (i.e. for stability calculation) rather than internal moments that one would use for structural calculation. To get something like the root bending moment, you probably want to add up the individual moment contributions of each individual panel on the wing. To do that, you'll likely want to use:

vlm3.vortex_centers, which is an Nx3 ndarrray giving the effective aerodynamic center of each panel
vlm3.Fi_geometry, which is an Nx3 ndarray that gives the local (inviscid) forces acting on those respective aerodynamic centers

Both of these quantities (location and force) are expressed in aircraft "geometry axes" (x is backward, y is right, and z is up).
To get the root bending moment, I imagine you'll want to do some kind of
np.cross(vlm3.vortex_centers - wing_root_location, vlm3.Fi_geometry, axis = 1)

-type operation, though isolating which panels came from which wing might be tricky...

You also might consider what the goal of your optimization is - if you're trying to do spanload optimization where you get minimum induced drag for a given root bending moment, I believe there's a closed-form solution for that in a 1933 paper by Prandtl!

Hi @peterdsharpe,
Good to know you are in good health. Keep it that way ;) I am writing from Madrid, Spain. I am glad you had the chance to live in Spain, specially in Salamanca (beautiful city).
For the moment I am only trying to asses the effects of adding the winglets to the wing, no optimization needed for the moment.
If the line of code you gave me will add up all the contributions (wing + winglet), it is good enough. I don't need to separate them for the moment either.

Yes, it should do that (as long as you have just one wing in your simulation)! I would also check that code, as I haven't actually tested that - that's just pseudocode for a basic r-cross-f-like moment calculation!

Okey, I see.
I was modeling the winglet with two separate Wings, like a vertical stabilizer. But by the looks of your comment, I should perhaps add an extra WingXSec at the end of my wing, right?

Either one should be fine - those should generate identical results!
Sorry - I should have worded my comment better. Basically, that pseudocode that I wrote above will assume that all panels on the airplane (from all Wings and all WingXSecs) are exerting a moment on the wing root. For a flying wing, this is the case. However, for a conventional-configuration airplane (i.e. with a tail), this is not the case (the forces on the tail do not contribute to the main wing's root bending moment).

Great!
Another question, since you seem to be available now. I've notice that for the vertical stabilizer you have put a small gap between the HTP and the VTP. Should I do the same with my winglet?
That is, is there any problem if the bodies "collide"?
Thank you.

Sure!
From a theoretical standpoint, there shouldn't be a problem with making them coincident - my hunch is that that'll be fine. I especially think you'll be fine if you're using CasLL1, though I think you should still be fine if you're using one of the many VLM-like methods.
However, you might run into numerical issues if you have any extreme wing twists at that intersection? Again, I don't think there would be a problem, but this might be something to play around with! Any problems will likely be immediately obvious, as the issue you might face is that a vortex filament gets too close to a collocation point and causes a singularity (i.e. lift and drag values will shoot off to infinity and be very obviously incorrect).

What is the difference between CasLL1 and the VLM methods? I guess the first one is not a lattice vortex method?
I think I might be running into those issues you mention, I'll have a look at it tomorrow.
Thanks!

Great question! CasLL1 is a modern implementation of a nonlinear lifting-line method. It's similar to the method this paper describes, but I hadn't read this paper at the time of coding CasLL1 so there may be small differences here and there:
https://arc.aiaa.org/doi/abs/10.2514/2.2649
Compared to one of the many VLM methods, there are pros and cons:
Pros:

Much, much faster (10x or more compared to VLM)
Fully nonlinear, which is extremely useful for:

Design problems at low Reynolds numbers where the CL-alpha polar is highly nonlinear due to viscous
decambering effects. See the following polar from a regular NACA 0015 @ Re = 1e5:

Design problems near stall, where the CL-alpha polar is highly nonlinear and you might have local stall.
Design problems with shockwaves (as long as they're not too strong), where CL-dependent shock formation can cause strange shock-boundary-layer interaction effects.

Predicts viscous drag and wave drag (as long as your CDp_function models that - more on that in the "Notes" section below).
Fuselage modeling is implemented with a coupled slender-body model. (There's no reason this can't also happen in a VLM-like method, but I've only gotten around to it in the LL model, since that's now my workhorse for research these days).

Cons:

Actively in development, so not as well-validated as the VLM solvers (especially VLM3 from the aerodynamics_legacy_v0 package, which has been extensively tested).
While I've implemented the effects of sweep and dihedral in a way that's theoretically sound, it's still fundamentally a lifting-line method. This means that you'll get modeling error at sharp breaks in sweep and dihedral. I've noticed that accuracy here tends to break down past around 35-40 degrees of sweep or so. I haven't fully tested the limits of dihedral, but I'd imagine you might run into problems with a sharp 90 degree wingtip.

Notes:
If you use CasLL1, beware that you should specify the input arguments CL_function, CDp_function, and Cm_function to any Airfoil-class objects that you create. In the future, this will be automated, but for now, you need to specify this. The Airfoil constructor has instructions on how to do this, and aerosandbox/library/airfoils.py has examples.


reload support for Vim list source?

[x] I have read through the manual page (man fzf)
[x] I have the latest version of fzf - 9c293bb
[x] I have searched through the existing issues

Info

OS

[x] Linux
[ ] Mac OS X
[ ] Windows
[ ] Etc.

Shell

[x] bash
[ ] zsh
[ ] fish

Problem / Steps to reproduce
I notice in https://github.com/junegunn/fzf/issues/1750 support for reload which is extremely useful. The example at https://github.com/junegunn/fzf.vim#example-advanced-ripgrep-integration shows how to pass a command to reload:
function! RipgrepFzf(query, fullscreen)
  let command_fmt = 'rg --column --line-number --no-heading --color=always --smart-case %s || true'
  let initial_command = printf(command_fmt, shellescape(a:query))
  let reload_command = printf(command_fmt, '{q}')
  let spec = {'options': ['--phony', '--query', a:query, '--bind', 'change:reload:'.reload_command]}
  call fzf#vim#grep(initial_command, 1, fzf#vim#with_preview(spec), a:fullscreen)
endfunction

command! -nargs=* -bang RG call RipgrepFzf(<q-args>, <bang>0)

I also note from https://github.com/junegunn/fzf/blob/master/README-VIM.md#fzfrun that it's possible to start fzf with a source that is a Vim list, e.g.:
call fzf#run({'source': map(split(globpath(&rtp, 'colors/*.vim')),
            \               'fnamemodify(v:val, ":t:r")'),
            \ 'sink': 'colo', 'left': '25%'})

What we would like to be able to do however is reload fzf with an updated Vim source list, specifically to use the value returned by a Vim function parameterised by the value input to fzf.
The actual use case here is the LSP workspace symbol method. The usage we are imaging here is that a value typed in the fzf finder would act as a query to the symbol method, and then fzf would be used to select the result.
Does this make sense as a use case for reload? Could it be make to support a source that is an input list?
Many thanks
cc @findleyr

https://github.com/junegunn/fzf.vim/issues/948 should answer your question.

Apologies, my issue search failed to uncover that. Thank you for linking to it.

No worries. People creating issues across two repos, it's rather hard to find actually.


test32

Codecov Report

Merging #26 (17e1ce0) into master (3dd1d62) will not change coverage.
The diff coverage is n/a.

Flag
Coverage Δ

packit-e2e
51.77% <ø> (ø)

testsuite
24.07% <ø> (ø)

unittests
11.11% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

/packit test


Wiki Home

Hi Mauricio!
Great job so far, let's just edit a couple of things:
First:
The title of the page ("Home") will show up as an H1, all the titles that we have in the body of this wiki page should be an H2 to make it easier to read. H2s will still have the line below, only the font size will change.
Second:
Purpose
This is a recreation of the website Etsy entirely out of Javascript with React. Its primary purpose is as a proof of concept.
We are going to use a lot more than JS and React. We will use PostgreSQL as the db, Ruby on Rails for the backend; JS, React.js, and Redux.js for the UI, as well as HTML & CSS. All these technologies make our Full Stack.

I noticed you made one page for Server. However, we need one page for Schema and another one for Routes, here is the wiki example: https://github.com/appacademy/bluebird/wiki

Thank you!
Fixes:

- # Introduction
+
Introduction

- # Purpose
+
Purpose

- This is a recreation of the website Etsy entirely out of Javascript with React. Its primary purpose is as a proof of concept.
+ This is a recreation of the website Etsy entirely out of CSS, HTML, Javascript, React.js, and Redux.js for
+ the frontend; PostreSQL and Ruby on rails for the backend. Its primary purpose is as a proof of concept.

- # Index
+
Index

I've split the Schema and Routes pages.


Skip compiler activation (on Linux) for 4.1.x

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Fixes https://github.com/conda-forge/ctng-compiler-activation-feedstock/issues/74

Backports PR ( https://github.com/conda-forge/r-base-feedstock/pull/213 ) to 4.1.x.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please re-render

Thanks Devon! 🙏

@dpryan79, there is an unresolved conversation in both of this PR

Not following Isuru. The cert issue remains open. So not seeing a way to fix Windows builds without that

It was fixed by https://github.com/conda-forge/r-base-feedstock/commit/e836ce0d68860989a6ce67a6d1b915096eb5d882 already in main

@dpryan79, please revert this PR as there is an unresolved conversation. Or please backport https://github.com/conda-forge/r-base-feedstock/commit/e836ce0d68860989a6ce67a6d1b915096eb5d882 and re-enable windows.

I don't think we should be using insecure like this

Then please revert this PR.

Why is reverting required? Re-enabling Windows is still possible without reverting

Because it's rude to merge a PR with an unresolved conversation initiated by a maintainer without giving any reason.

If it is helpful to add PRs that drop the skip and re-render, I'm happy to do that, but don't have bandwidth to fix the Windows issues here more generally. If that seems like a reasonable solution, I can pick that up tomorrow

@dpryan79, I'd still like an explanation for why this PR was merged

@isuruf sorry, I thought the discussion had ended when I merged. I can certainly revert the changes here if desired.

I can certainly revert the changes here if desired.

I'm looking at fixing the 4.1 Windows build at gh-224 ;) -- I hope that could resolve the issue!?


Static Fetching

Summary
At the moment fetching is currently forced into a Vec<u8>. This was for easy portability into having dynamic loading in the future, and to not change the API later.
It would be nice to have the ability to actually fetch it as a constant &'static [u8] and since it is loaded at compile-time that is totally possible. Since the future will have dynamic loading though as well, the API will be Option<&'static [u8]> where Some(T) will be for all compile-time loaded variants that actually have a static lifetime and None will be returned for the other cases.

Done #8 .

Done https://github.com/Shadorain/asset-derive/pull/8 .


Changing the length parameter of Vectors layer to something more explicit

Quick summary
Change the parameter length of Vectors layer to something like scaling_factor, length_multiplier or length_scaling.
Overview of design need
This is a follow-up issue to the discussion in #5740 in which @jni and @brisvag suggested renaming the parameter length of Vectors layer to something more explicit.
@jni:

It's also unclear what length means for the vectors — isn't that implied in the data? I see that it's multiplied by the second component of the vector data but I don't understand why...

@jules-vanaret:

Regarding your comment about the length parameter: maybe it has been ill-named. The actual physical lengths of vectors are indeed directly given by the magnitude of the second component of the vector data, but the length parameter is an extra multiplicative factor that is applied to all vectors at the same time to allow the user to scale them in the viewer (e.g when the physical lengths are too small and are not directly visible on the viewer).
Maybe scaling_factor or vector_scale would be a better name ?

@brisvag:

Yeah, I always [thought] length was a bad name, but it's pretty central and user-facing, so if we change it we should introduce deprecations (shouln't be too hard to do, happy to help here if you need it). I like scaling_factor, or ever more explicitly length_multiplier or length_scaling.

This is tricky for me to solve because it requires introducing the new name while keeping proper deprecation notices of the old name for the user, which I have never done.

This is tricky for me to solve because it requires introducing the new name while keeping proper deprecation notices of the old name for the user, which I have never done.

If you want to tackle this, you can take a look at how it's done in image.py: https://github.com/napari/napari/blob/5ce6fc9a6beb45cc819a6f4c8a9ccebdef801667/napari/layers/image/image.py#L224-L229

Ah perfect, thank you for pointing me in the right direction !
As to which name should be chosen, I vote for length_multiplier. :wink:

length_scaling is also a good candidate... but I don't have strong opinions here.


nodetool: add --load-and-stream option to refresh

This information is forwarded through JMX to Scylla, adding an extra
{"load_and_stream", "true"} entry in the POST request to Scylla's HTTP API
at storage_service/sstables/{keyspace} endpoint.
More about this feature: scylladb/scylla#7846
Mutually bonded change: scylladb/scylla-jmx#176
Fixes #253

LGTM. Do we have any way to test this automatically? With unit test or dtest?

@scylladb/scylla-tools-maint ping
(dtest is already merged and I promise I'll remember about the docs)

@scylladb/scylla-tools-maint ping


Improve usability of the mini color dialog

I have recently implemented a mini-color-picker in the experimental branch. This issue is to track some potential improvements.

[ ] Keyboard support (eg. Enter, Esc)
[ ] Remember recently used custom colors as a third swatch row. Store in global settings.
[ ] Allow you to switch between HEX, RGB, and HSL textbox modes similar to the devtools implementation
[x] Apply color changes in real time and remove the "Cancel" and "Accept" buttons at the bottom.

Color picker "accept color" de-selects the current tool. It shouldn't.


what is the status of this project?

Hello,
I am interested in calling Apache Ignite from Rust (from micro-services?) and I would like to know more about your project.
Is this a dead-end?
What have you learnt so far?
Do you have any advice?
Happy to discuss via email if you prefer.
Many thanks
Yuri Budilov
Australia

Hello yuri.
my road is same with you . (Apache ignite from Rust service)
can discuss via email ??
<EMAIL_ADDRESS>


license

Would you mind adding an explicit license?
It would make it easier to reuse.
See e.g. Scipy/Numpy/Pytorch use 3 clause BSD variants,
but there are plenty of options: MIT, (A)GPL, Apache, MPL, public domain, etc.

Thanks for you suggestion. I had added a license.

Thank you for publishing your work.


Update syntax to PHP 5.4

There will be soon some mix between array() and []. To avoid this, when updating to Laravel 5, we could update the array syntax as well.

Curiously it seems there are already some [] in code. No one is using 5.3 anymore? cool :)


Initial Android makefile

That's a good point.
Honestly, I am not aware of any kind of CI tool for Android package testing.
I need yaml (more specifically PyYAML, but I also want the native bindings) for an internal project, but figured it would be nice to contribute back for other people.
I opened pull requests for picocom and i2c-utils too to add Android makefiles.
But as far as I can tell, there are very few *nix packages which support building on Android, Google mostly just forks them and converts them into Android projects.

Would you be open to moving this into a contrib/ directory then?

Sure, works for me.

@raymanfx can you update your PR to do that please?

Sorry, I've been out of the loop for a while.
Does this look fine to you?


config/admin/seo.go:22: not enough arguments in call to seo.New

I got this error :
config/admin/seo.go:22: not enough arguments in call to seo.New

The problem solved by ignore some last commit in qor/seo module. Please check new commits in this module.

 Please check new commits in this module.


Only require significant parameters to be supplied in the params_str …

…when trying to create a task instance from the str->str hash.
Otherwise, the method results in a KeyError since insignificant parameters are not incorporated in the str->str hash created by the to_str_params method.

Would be good to be able to set insignificant parameters though. Can we fix the underlying issue instead? I might be misunderstanding

If the parameter is supplied in the params_str it will be set there. Maybe it would be nice to consider insignificant parameters in "to_str_params"

Sorry for our intermittent build falure. Since it's fixed, do you mind rebasing it? :)

@ntim I think you're right about considering insignificant parameters in to_str_params (or as @erikbern put it - fixing the underlying issue). I created #1109 that fixes the issue and it comes with a test case that would have avoided it in the first place.

Closed in favor of #1109


fix/find-manifest-in-static-root

This PR addresses Issue #22 by checking for the existence of asset-manifest.json in STATIC_ROOT when it can't be found in the Create-React-App build/ folder. This makes it possible to run collectstatic to pull in CRA files into STATIC_ROOT, then completely remove the CRA build/ folder to reduce production filesystem footprint.

This fix has been released in django-cra-helper==1.2.3.


Test the importer with data coming from a sample Shopify store

This will put the great work that has been done into test and help in smoothing out any rough edge that we might otherwise miss.
Originally part of the roadmap in #5

This has been done 👍👍👍


[Event Request] Codeunit 226 CustEntry-Apply Posted Entries - OnBeforeApply

Please add a new publisher event to the function Apply as follows:
[External] Apply(CustLedgEntry : Record "Cust. Ledger Entry";DocumentNo : Code[20];ApplicationDate : Date) : Boolean
//>> Start New Publisher Call
OnBeforeApply(CustLedgEntry, DocumentNo, ApplicationDate); //C09032.n
//<< End New Publisher Call
WITH CustLedgEntry DO BEGIN
  IF NOT PreviewMode THEN
    IF NOT PaymentToleranceMgt.PmtTolCust(CustLedgEntry) THEN
.
.

New Publisher Event:
LOCAL [IntegrationEvent] OnBeforeApply(VAR CustLedgerEntry : Record "Cust. Ledger Entry";VAR DocumentNo : Code[20];VAR ApplicationDate : Date)

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Add support for preview when collapsed

Instead of showing three dots when collapsed

would be great to set which fields are important and try to show them in preview when collapsed:

@igo  It looks easy to implement. How about adding a collapsedPreviewLength prop?
<JsonView
+  collapsedPreviewLength={12}
/>

To make this useful I need to select which fields to show. collapsedPreviewLength would be useful to limit how many of those fields would fit on the screen.

@igo Would it be acceptable if the API is designed like this?
<JsonView
+  collapsedPreview={12}
/>

<JsonView
+  collapsedPreview="some text"
/>

<JsonView
+  collapsedPreview={(value, expandKey = '', level, keys = []) => {
+     return "some text"
+  }}
/>

I do not fully understand your suggested API. I was thinking about something like this:
{
"user": { "username": "tim" } // firstName intentionally omitted
"address": [{"city": "NY"}]
}

<JsonView
collapsedPreviewKeys=['user.username', 'user.firstName', 'user.address.[0].city']
collapsedPreviewKeyName={true/false} // would show "username -> tim, city -> NY" if true else "tim, NY"
/>

@igo I think callback functions would be more flexible.
var object = {
  "user": { "username": "tim" }
  "address": [{"city": "NY"}]
}

<JsonView
  value={object}
  collapsedPreview={(value, expandKey = '', level, keys = []) => {
    if (expandKey == "user") {
      return value.username
    }
    if (expandKey == "city") {
      return value
    }
    if (keys.join(".") == "user.address.0.city") {
      return value
    }
  }}
/>


Nomad Hotfix NeXus parsing

There is an error in nomad, which is probably due to the metainfo refactoring which runs into a keyerror. This fixes it.
We should go through the nomad metainfo and fix everything after the workshop. There are a lot of warnings and errors.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.04%) to 44.543%

Totals

Change from base Build<PHONE_NUMBER>:
-0.04%

Covered Lines:
4902

Relevant Lines:
11005

💛  - Coveralls


fix: removed blur styles from iOS picker

Details

This PR adds styles to the React Native Picker Input such that the done button shown on the picker has a fixed font size when long pressed, similar to how it looks like when the button is simple pressed.
Fixed Issues

$ https://github.com/Expensify/App/issues/17180
PROPOSAL: https://github.com/Expensify/App/issues/17180#issuecomment-1502619821
Tests

On iOS app, Go to Settings -> Click profile picture
Click Personal details -> Home address
Click on country to open picker
Long press on Done button
Verify that the font size of Done button does not change

[x] Verify that no errors appear in the JS console

Offline tests

N/A
QA Steps

On iOS app, Go to Settings -> Click profile picture
Click Personal details -> Home address
Click on country to open picker
Long press on Done button
Verify that the font size of Done button does not change

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://user-images.githubusercontent.com/30054992/231311014-1c5d6a06-108e-4ae8-a6e8-dce39bba5441.mov

Mobile Web - Chrome

https://user-images.githubusercontent.com/30054992/231311030-029f0ba8-9777-4fe3-b5ac-056fe62daccd.mov

Mobile Web - Safari

https://user-images.githubusercontent.com/30054992/231311025-945b479f-cd99-4431-88b1-1eed7a43a36e.mov

Desktop

https://user-images.githubusercontent.com/30054992/231311019-6abe7abe-d4bd-478f-b7aa-c3d169ffc674.mov

iOS

https://user-images.githubusercontent.com/30054992/231311021-fd6026d0-603d-447a-9408-b61b6b39b09a.mov

Android

https://user-images.githubusercontent.com/30054992/231311028-219711aa-4dfd-41be-905c-41f4a76f13d2.mov

@luacmartins @eVoloshchak One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/luacmartins in version: 1.3.0-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 1.3.0-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


typo correction for Tax data  line 779

deleted 'unkown'
replaced it with 'unknown'

[ ] My submission is formatted according to the guidelines in the contributing guide
[ ] My addition is ordered alphabetically
[ ] My submission has a useful description
[ ] The description does not have more than 100 characters
[ ] The description does not end with punctuation
[ ] Each table column is padded with one space on either side
[ ] I have searched the repository for any relevant issues or pull requests
[ ] Any category I am creating has the minimum requirement of 3 items
[ ] All changes have been squashed into a single commit

Hi @kithstack1
Thanks for your contribution ;)
We have some problems with Public APIs, so we won't be able to review/add this improvement right now.
Read this issue for more information, please: https://github.com/public-apis/public-apis/issues/3104


Widget to show tracking data

Request to add a enonic widget that shows some statistics about the users site/page?
Some statistics that would be useful to see:

Number of unique visitors
Number of views on this page
Total time spent on this page, in seconds

Having this for a day, week, month and year would give quick access to the data.
Could the reporting api  be used to create this?

I'll make a task for this @poi33 and we'll see what we could do. Thank you for the suggestion!

As far as I can tell, this was solved in https://github.com/bouvet-apps/app-matomo/pull/9/files 😊


Auto Paste not wroking properly

I have seen that there is a nother issue, with my exact same problem, but it is no longer activa as it seems, so I decide to write a new one.
Its pretty much the same thing, it works sometimes, but then its back to poe getting lit up on the taskbar, and nothing pasting.
I am running the latest version on windows 10.
I have tried restarting poe and slim trade and switching between the pasting modes, but nothing seems to fix the problem.

I forgot to mention that I also tried running it with the script mentioned on the other thread.

Now that I'm actually playing more, I've run into this issue myself quite a bit. I don't have a solution yet, but will be able to debug it much better now that I can actually reproduce it myself.

Fixed in v0.3.0. More technical response here.


WinUI 3.0 in a desktop autocad plugin

Hello,
I am developing an autocad plugin which is a dll actually called from Autocad.
I want to be able to put winui into my windows, which i open in response to user commands.
Are there any obstacles to this right now?

I don't know very much about the structure of Autocad or its plugins, are they Win32 apps? WPF? something else? Its tough to say for sure without knowing the specifics, can you share more info?
@MikeHillberg fyi

They are win32 apps and they use mfc.
On Tue, Dec 1, 2020, 2:16 AM Stephen L Peters<EMAIL_ADDRESS>wrote:

I don't know very much about the structure of Autocad or its plugins, are
they Win32 apps? WPF? something else? Its tough to say for sure without
knowing the specifics, can you share more info?
@MikeHillberg https://github.com/MikeHillberg fyi
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/3717#issuecomment-736132536,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIXS4LX7VH43OWELKN3ATDSSQYWNANCNFSM4UGUVLQA
.

It's unlikely that this scenario will be enabled by the next release of XAML Islands.  XAML Islands content (the WinRT types used) requires registering the classes that will be used by the Island. This registration is done in the application manifest, which goes with the EXE of your app. Given this is a plugin and I guess you won't be able to add the info to the manifest, you won't be able to load the types of the island.

Can I register them programmatically?
Is this an option?

No, it's not an option. It will be great to do it, but it won't happen in 2021 for our current engineering plan. You can open a feature request for asking about it.

Any new ideas? Is .Net Standard a way?

Any updates on this?

Hi all, I've just created a feature request that may interest you. I've aimed to define the scope of the use case as broadly as possible.


@color/white_two

Please provide as much of the following information as possible. Please do not raise issues to ask for help developing your app.
Expected behaviour
Actual behaviour
Steps to reproduce
(Include your setup code, and where relevant, your layout XML)
Affected devices
(Specific devices, screen densities, SDK versions)
Affected images
(Attach images you have problems with)

Sorry. This was a miss click(( Can't find how to delete this issue.


Context menu text is too big when using Native titlebar style on system with KDE

Type: Bug
Does this issue occur when all extensions are disabled?: Yes
VS Code Version: 1.92
OS Version: Arch Linux with latest updates (08.02.2024)
Steps to Reproduce:

Open the editor
Try editing some file
Click right mouse button in the editor to trigger the context menu

The same happens when you click on the 'Manage' or 'Accounts' button in the bottom-left corner.
 This issue seems to be a duplicate of https://github.com/microsoft/vscode/issues/224515

Yeah I really don't like the new context menu. This issue seems to be a duplicate of #224515

Oh, it really is. I saw this issue when I was looking for some existing ones, but I forgot to scroll to see the same problem in the issue you mentioned.

Same happened to me.
https://github.com/microsoft/vscode/issues/225033

when using Native titlebar style

Thank you for providing a fix btw :)

Moreover colors from the current VSCode theme does not apply to it.
My desctop UI menus are light and VSCode  theme is dark.
 It would be great to separate the configuration of "window.titleBarStyle" into two distinct settings: "window.titleBarStyle" and "window.contextMenuStyle". This would allow users to choose a "custom" style for the context menu while keeping the title bar as the native style. Currently, setting "window.titleBarStyle" to "custom" causes the window decoration to be lost on Wayland, or some users may just prefer to retain the native title bar style.

Just suggestion. It would be great to separate the configuration of "window.titleBarStyle" into two distinct settings: "window.titleBarStyle" and "window.contextMenuStyle". This would allow users to choose a "custom" style for the context menu while keeping the title bar as the native style. Currently, setting "window.titleBarStyle" to "custom" causes the window decoration to be lost on Wayland, or some users may just prefer to retain the native title bar style.

Agreed.

/duplicate https://github.com/microsoft/vscode/issues/224515


Documentation issues

I'm sorry, I found that my user interface doesn't have a translation option, I suspect that my src folder is using a very old version, but the src folder in the beta is not complete, can you send me a full src folder?

In addition, I found that when I switched to the comfyui interface, many plugins could not run, such as workflow management plugins, model preview plugins, etc., is there any way to make them run

If you need to reinstall, follow the steps here: https://github.com/Stability-AI/StableSwarmUI?tab=readme-ov-file#installing-on-windows
If you have an old version, you can just run the update-windows.bat
Comfy addons should all work on latest version, Manager is known to work.


Add debug option to show what rule(s) caused the formatting

It seems that understanding why a line was formatted a given way is a guess and check process. Is there a way to write out a {filename}.cs.debug file that would show in comments (or otherwise) what rule(s) caused a line to change?

The typical process I follow when debugging formatting.

Format code using the playground
Use the AST tab to determine what type of CSharpSyntaxNode represents the code I'm trying to debug

Optionally use SharbLab instead. It maps code to AST

Starting place to look in code is typically Printer/[CSharpSyntaxNode] or going forward SyntaxPrinter/SyntaxNodePrinters/[CSharpSyntaxNode]
Use the Doc tab to see what kind of Doc elements are being used to format the code.

The thing that would help me the most, would be if the playground could map between code, AST and doc. Similar to what SharbLab does

But I'm not sure if it is worth the effort it would take.


[Apple Reminders] Pre-fill the Create Reminder command with text from My Reminders search

Extension
https://www.raycast.com/raycast/apple-reminders
Description

I searched for a reminder that wasn't in the My Reminders command. I hit Enter to create a new reminder, but then I was surprised to see that the reminder title wasn't pre-filled with the text that I had already entered in the previous command.

Who will benefit from this feature?
No response
Anything else?
No response

Thanks for adding this @michalzuch !


Update About “about”

Automatically generated by Netlify CMS

👷 Deploy Preview for dynamic-cheesecake-5fbd8b processing.

Name
Link

🔨 Latest commit
4c1dee3c91a2eb98d7c67f5f04b2e167d3e32cc6

🔍 Latest deploy log
https://app.netlify.com/sites/dynamic-cheesecake-5fbd8b/deploys/62eef104a20cbe0008e35753


Add a table function that works with any enums

As long as we have an enum of tuples or enum of maps, we can render them with pagination and what not.

Maybe we should call it data_table. The reason for this is because we may also want to introduce something like data_chart, which is a chart where you receive the data and you can choose in the UI the different ways to represent it (Deepnote has a similar feature).


Adding Further Mod Support: Quark and Shield Expansion

I'm glad that Oreganized added support for Create and Farmer's Delight and i have more ideas:
Quark adds a tool named Pickarang and they can be upgraded from diamond to Netherite, an Electrum Pickarang can be a very nice addition to them. Plus vertical slabs for Glance blocks and an Electrum shield for Shield Expansion can also very neat. These are my ideas for further compatibility

an electrum pickarang should fly faster than a normal pickarang


fix slack url

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Update slack invitation link to CNCF, ref: https://github.com/kubeedge/community/issues/185
Which issue(s) this PR fixes:

Fixes #

/lgtm

/lgtm

Please rebase new main branch
Done

/lgtm


Update dependencies + Run Tests

Fixes several security issues with outdated packages.
Closes #17

Closing as repo is unmaintained.


Add angular-touch as a dependency to package.json

Hi,
Shouldn't angular-touch be specified as a dependency in package.json?

still using bower on this projet. not sure if its a good idea to duplicate dependencies to package.json ?

OK, I see your point. I, on the other hand, use both bower and npm in my project (with many more packages managed by npm) and I'm trying to use npm only. But it's OK if you prefer bower.

i don't, its just historical :) you're welcome to submit a PR to remove it if you will
Thanks


✨ Defect-aware on-the-fly SiDB circuit designer

Description
This PR adds the defect-aware on-the-fly SiDB circuit designer and supports all 2 input functions.
Checklist:

[x] The pull request only contains commits that are related to it.
[x] I have added appropriate tests and documentation.
[ ] I have made sure that all CI jobs on GitHub pass.
[ ] The pull request introduces no new warnings and follows the project's style guidelines.

The Windows CI failing is not your fault. It stems from the changes I made to the technology mapper interface. MSVC seems to have issues with the mockturtle::map function. I haven't figured out a fix yet. Don't worry about it right now.

The Windows CI failing is not your fault. It stems from the changes I made to the technology mapper interface. MSVC seems to have issues with the mockturtle::map function. I haven't figured out a fix yet. Don't worry about it right now.

@marcelwa Do you already have an idea how to solve this? Thank you!

The Windows CI failing is not your fault. It stems from the changes I made to the technology mapper interface. MSVC seems to have issues with the mockturtle::map function. I haven't figured out a fix yet. Don't worry about it right now.

@marcelwa Do you already have an idea how to solve this? Thank you!

Unfortunately, I do not.

@Drewniok this PR can now be updated with the latest changes from main. Its tests should now pass 👍

@marcelwa Great! Thank you for your hard work!

I've made some adjustments to the code myself. Maybe reviewing the changes could be helpful for you. I've noticed quite some docstrings being out of sync. Not sure if I caught all. Particularly when parameters are no longer present, have been renamed, or are not documented altogether, the RTD documentation will have shortcomings.
Some points to which I had no answers myself, I left as comments. Thanks for your hard work!

Many thanks, @marcelwa

It seems not all references/calls to apply_sidb_on_the_fly_gate_library have been renamed. Thus, the build now fails

@marcelwa Many, many thanks for your tremendous work on this PR!

@marcelwa Many, many thanks for your tremendous work on this PR!

My pleasure. However, you definitely did all the heavy lifting here. Great addition to the framework. I'm glad it's finally merged 🙂


⚠ Bofrost.fr has degraded performance

In 80e0fb5, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 929 ms

Resolved: Bofrost.fr performance has improved in ea05305.


When logging on with webchat

in mIRC in every channel I see:
12:12pm * mrinfinity sets mode:
in Webchat I see:
12:12 *** mrinfinity (mrinfinity@291fe5) has joined the channel
12:12 *** Channel mode is +
12:12 *** The topic is: <#netops> NETWORK ops channel for IRCops that lead their communities. Paving a decentralized foundation for the * | sysadmin doc: https://docs.google.com/document/d/1m6rZE5zMQkjJVksgAyb67WgNgYIb01H5f-cGnaqoPb0/edit?usp=sharing
12:12 *** Topic set by mrinfinity on 15 April 2020, 21:32:58
12:12 *** Channel mode is +nst
Node the channel mode is + line

This should be fixed with latest commit.


Token parsing is not consistent between ExtractJwt.fromHeader and the default token parser

ExtractJwt.fromHeader and the default token parser are inconsistent in functionality.
The default token parser accepts tokens in this form:
Authorization: JWT JSON_WEB_TOKEN_STRING.....

fromHeader, however, does not work with the previous form. Instead it requires the following:
Authorization: JSON_WEB_TOKEN_STRING.....

I wish this was mentioned in the documentation. Consistent implementation would be even better. Thanks for the library in any case!

There are multiple extractors that read the JWT from headers, you may just be missing the differences.
extractors.fromHeader  reads the JWT from any header, allowing you to specify the header name.
extractors.fromAuthHeader works just like the default token parser and reads the JWT from the authorization header if and only if the authentication scheme is 'JWT'
extractors.fromAuthHeaderWithScheme reads the JWT from the Authorization header and allows the user to specify the scheme they expect so they can use something different from JWT.
Each of these extractors was added in response to multiple feature requests.  I don't think its a matter of inconsistent implementation as much as it is enabling as much flexibility as possible.

Closing but if you want to suggest some documentation improvements feel free to submit a pull request.

extractors.fromHeader('Authorization') should be interchangeable with extractors.fromAuthHeader(). This is not the case.
The bug responsible for the inconsistency is due to the fact that fromHeader() does not account for the four first characters in JWT ${token} as fromAuthHeader() does.


Removed ParseResult, replaced it with Optional

Resolves #142.
Fairly mechanical global replacement:

ParseResult -> Optional<Environment>
.succeeded -> .isPresent()
.environment -> .get()

Additionally, since success() and failure() were in ParseResult, they were moved to Util. It's a point of discussion whether they should exist after this change, since they are essentially calls to Optional.of() and Optional.empty(). I personally think that reading success() or failure() is more readable, so I prefer to keep them for the time being.
Biggest functional change is in BaseCallback, where handleFailure() doesn't get an Environment passed in anymore, since it's not available on failure. This is actually better since it was ambiguous which Environment you would receive in the old scenario.
Finally, when converting the callback handling, I found an == compare on Token instances in Callbacks.handleCallbacks() which is now replaced with a call to equals()! (#130)

Bettercodehub is complaining again, but a fair point again: Util is slowly turning into a place that too many things depend on.

Biggest functional change is in BaseCallback, where handleFailure() doesn't get an Environment passed in anymore, since it's not available on failure. This is actually better since it was ambiguous which Environment you would receive in the old scenario.

I don't really like this change in functionality.
A common complaint that drove us to add callbacks is: "Why did my parse fail?".
We added the callbacks to handle not only the "happy case" of successful parses of tokens, but also to analyse the case of parsing that fails. If we do not pass an Environment into handleFailure(), there is no way of knowing why something went wrong. I think it's very useful to pass the Environment that was used when the parsing failed; for example a developer can evaluate an expression on it, to see why it failed (for example, why did a ref fail?).

But then you oppose the entire change? Because there's nothing to pass if we make this change to the API...

But then you oppose the entire change?

I haven't rejected the PR, right? 😁
Haven't taken the time yet to look at the entire change to see if I oppose all of it 😉 Overall I like the idea of removing ParseResult. I just wanted to reply to that detail of your description.

Token has now changed to:
    public Optional<Environment> parse(final String scope, final Environment environment, final Encoding encoding) throws IOException {
        final Encoding activeEncoding = this.encoding != null ? this.encoding : encoding;
        final Optional<Environment> result = parseImpl(makeScope(scope), environment, activeEncoding);
        environment.callbacks.handle(this, result);
        return result;
    }

If we do want to pass an Environment to callbacks in case of a failed parse, we could just pass in the environment variable, i.e. the environment that we had before the failed parse.
That does mean that we cannot let the Callbacks determine when a parse failed or succeeded, but we have to do it here. So, our code would change to something like:
        ...
        final Optional<Environment> result = parseImpl(makeScope(scope), environment, activeEncoding);
        if (result.isPresent()) {
            environment.callbacks.success(this, result.get());
        } else {
            environment.callbacks.failure(this, environment);
        }

Not too bad, right? Especially if we move this code into a separate method.

Let's see what I can make of it :-)

Note by the way that BaseCallback is just an optional base class. The callback mechanism itself doesn't distinguish between succeeded/failed parses and just passes along the return value. But essentially that has the same result as removing it from the BaseCallback's failure handler: no access.
I agree that passing the original Environment may be a solution, especially since that is less ambiguous than the original approach, where each Token could determine which Environment to return upon failure.
We could also change the overall callback interface to always pass through the before and after Environment. I mean if we want to make debugging easy...

Ok so the BiConsumer<Token, Optional<Environment> is gone and the Callback is now back. Which is actually nice because it makes way more sense to implement the latter than the former. Along with the better method naming (handle() instead of accept()).
The functional interface is then: Callback.handle(Token token, Environment before, Optional<Environment> after) and BaseCallback turns that into: handleSuccess(Token token, Environment before, Environment after) and handleFailure(Token token, Environment before).
Very nice! This also allowed me to reinstate a check in the unit tests (CallbackTest line 224).


Add database to project

Adds database setup and connections to project. Includes new musicbrainz connection for getting information on album genres if available (since Spotify appears to have none).
Adds a basic settings page to the frontend for populating user data.

@JackMead Realise some refactoring might be due here. Thought I'd save that for a following PR to reduce the number of changes you have to muddle through.

(Note to self to also review format-on-save)


Fixed incorrect description (Resolves #1841)

Was previously #1903, but for some reason, that one got all muddied up with a bunch of commits.

Formerly #1903, but now cleaned up commits.

Thanks @sdomino!


Drag-and-drop not working

https://www.neverendingchartrendering.org/
Hi, this site doesn't seem to work correctly in ungoogled chromium 79.0.3945.117 on Windows 10 when dragging the image onto the panel.
Tested it in firefox and it works fine.
Any fix?
EDIT: installing extensions by dragging the crx files into the extensions page also does not work.

I can confirm this as an issue on ungoogled-chromium 79.0.3945.130 on Windows. Haven't tried this on Linux yet, though.

On Linux, I've been having troubles dragging and dropping for a while now, such as files from a file manager. Maybe dragging and dropping is broken by a patch?

Not working either on Linux Mint 19.3 Cinammon 64bit. I tried installing NeverDecaf's Chromium Webstore. Dragged the CRX file and dropped it on chrome://extensions/ (Ungoogled Chromium Version 79.0.3945.130) but nothing happens. The screen changes to "Drop to install", but you drop and nada.

Similar to #834 "[Windows] Extensions don't install via drag-and-drop bug"
Drag and Drop doesn't work for several versions back now. Either plain text, links, urls, images, files, etc, from explorer or other applications, rendering some functions in various sites unusable, like VirusTotal for example.

All drag 'n drop works fine in 80.0.3987.87 (Official Build) (64-bit)
Windows 7 SP1 x64 - WIndows 10 LTSC

@flesti We haven't updated Windows support to version 80 yet. I don't know what browser you're using.

True. I just saw that you actually didn't.
But woolyss apparently thought you did
with a link to this.
It's strange because it does actually look like ungoogled chrome. I don't know the difference if there's any.

Portable Linux 64-bit v.80.0.3987.106-1.1 has drag-and-drop issue in Bookmark Manager.
Previous (portable) 78.0.3904.108-2.1 does not that issue.
No problems in 80.0.3987.106-1 provided by Debian (unstable).

Having issues with drag and drop installation of extensions in Windows 8.1 Pro 64 bit, Ungoogled Chromium version 80.0.3987.132

Ungoogled Chromium Version 80.0.3987.132
Linux Mint Tricia 19.3 (64-bit)
Drag and drop not working

and it's strange because in the macchome builds drag and drop works fine

Standard build of Eloston's ungoogled-chromium. All patches applied apart from "Safe Browser"

https://github.com/macchrome/winchrome/releases

Just to add some more context, I did a clean reinstall of the earliest version with installer executable (78.0.3904.70-1), and found some more verbose gui errors before adding the flag for chrome://flags/#extension-mime-request-handling
https://github.com/NeverDecaf/chromium-web-store/issues/8#issuecomment-60949477

#extension-mime-request-handling used to work, but doesn't anymore. now it just downloads the .crx file. I can no longer update chromium-web-store.

confirm

#extension-mime-request-handling used to work, but doesn't anymore. now it just downloads the .crx file. I can no longer update chromium-web-store.

Same for 80.0.3987.163

Similar issue in ungoogled-chromium 80.0.3987.1492, installed via Chocolatey.
Set the flag, dragged the CRX file to an extensions tag, and it just sits there spinning its wheels forever.

As of 80.0.3987.163, this issue apparently does not occur in Woolyss builds, which apparently do not use the Safe Browsing patches. We'll probably need to look at the patches related to Safe Browsing because they might be the source of the problem.

Hello all,
Few days ago, I made a video to show that drag-and-drop works nicely on our ungoogled-chromium version:
https://github.com/NeverDecaf/chromium-web-store/issues/10#issuecomment-595535488
Thanks for all developers and mainly Eloston. Very good job!
It is an hard work to maintain an ungoogled version of Chromium. Respect!

Linux versions aren't ungoogled though, I prefer staying with an ungoogled version like Eloston's.

Per https://github.com/Eloston/ungoogled-chromium/issues/988#issuecomment-611656303 I can't install any extensions at all.

I can't get any CRX files to install at all on:
Chromium	80.0.3987.149 (Developer Build) (64-bit)
Revision	5f4eb224680e5d7dca88504586e9fd951840cac6-refs/branch-heads/3987_137@{#16}
OS	Windows 10 OS Version 1909 (Build 18363.752)
JavaScript	V8 8.0.426.27
Flash	(Disabled)
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36
Trying to install through drag and drop or any methods mentioned in the FAQ only results in this happening indefinitely:

For anyone reading this, @xnaas's particular issue is https://github.com/ungoogled-software/ungoogled-chromium-windows/issues/23

For anyone reading this, @xnaas's particular issue is ungoogled-software/ungoogled-chromium-windows#23
EDIT: Workaround is to unpack CRX as a zip file (by renaming extension), then load the unpacked extension.

how to be renaming?

Just by renaming the file in the file manager (ie .crx to .zip)

Just by renaming the file in the file manager (ie .crx to .zip)

"Directory is not valid" alike an error appears when Ungoogled try to load unpack version of Web Store

Yeah, renaming from CRX to ZIP didn't work for me either.

On Debian/Ubuntu Linux builds, you can add downloaded extensions by opening them in the browser. You can also add extensions from CRX extractor. That's pretty much it. Even if I set the extension mime flag to always prompt for install, it doesn't auto-install downloaded extension files from elsewhere. Additionally, it doesn't do drag-and-drop.

@seanking2919 @linuxtopia Fair enough, I hadn't personally done that; I was able to get it to work by "unpacking" the CRX like Sean mentioned, then using the developer options add the unpacked extension (did this while booted into windows 10 1909)

@flesti How did you install version 80 official build?

On Debian/Ubuntu Linux builds, you can add downloaded extensions by opening them in the browser. You can also add extensions from CRX extractor. That's pretty much it. Even if I set the extension mime flag to always prompt for install, it doesn't auto-install downloaded extension files from elsewhere. Additionally, it doesn't do drag-and-drop.
Tested on Linux Mint 19.3 Tricia (w/ Cinnamon desktop; 64-bit)

Thank you. @seanking2919 changing flag from default to always prompt for install solved it for me too.
Arch Linux.

@flesti How did you install version 80 official build?

Turns out isn't official, it's builds from winchrome
suggested by woolyss identical to Eloston apart from the "Safe Browser" patch
https://github.com/macchrome/winchrome/releases/
sorry for the late reply

Compiled Debian buster changes with this fix (https://github.com/ungoogled-software/ungoogled-chromium-debian/commit/102dfab77f1f44ae312949166f632a1fdba3bfce), and it seems to be working. I tested drag-and-drop with Chromium Web Store and uBlock Origin; both seem to install correctly.
How frustrating that this issue was caused by a silly mistake, but fortunate that it was easy to find and fix. Hopefully #845 can eliminate issues like these...
Closing as I think the issue should be fixed, but testing is appreciated. If the issue persists, I'll re-open.

This is a little off-topic for this issue, but I notice the Windows binaries are pretty out of date. Does a community member need to step up and compile binaries? Do the current old binaries automatically update to the newest stuff?

@xnaas

Does a community member need to step up and compile binaries?

Roughly, yes. More accurately, someone needs to update the Windows patches.

@Eloston is there anything to doing builds other than git pull and following the instructions in the windows repo's build instructions? I see in one of their pull requests it seems like they are actually making changes in addition to building it. I didn't realize updates were waiting for community support, so I'm going to start building my own versions now. If it's just building and not improving I'd be happy to push changes up when I compile a new version.

@FrankSalmick Every platform has platform-specific patches that needs to be updated every time Chromium is updated. I'm not too involved in maintaining platform support except for Debian.

Drag-and-drop still ot working on Flatpak version 110.
Tested on: figma.com
Cant drop images to figma working area.
Works only with version from .deb package.

it works now... may be because i installed new video driver