gnome3.20: init at 3.20.0

Having fun trying to package Gnome 3.20.

migrated from pull request: #14290
issue: #14289

cc @lethalman @vcunat @jgillich

To be done:

[x] Aisleriot doesn't build (upstream bug, but this is not blocking for us) : fixed by making a libcanberra version depending on gtk+-3.20

[ ] Fix commits with (todo) in their message

[x] Enable Google authentication in evolution-data-server (keep it disabled for now)

[ ] Re-enable empathy (currently commented in both all-packages.nix and gnome3_20/default.nix)

[ ] Make sure  the nixos-rebuild output depends on latest libraries:
$ nix-build nixos/tests/gnome3-gdm.nix
$ nix-store -qR result

no gtk 3.18
no gnome 3.18
latest clutter

Removing mass-rebuild, historically we usually consider mass-rebuild things like openssl or stdenv, not graphical stuff.

In what way doesn't google auth work? It doesn't build or it doesn't work?

Soup is be necessary for gnome-maps: https://github.com/GNOME/gnome-maps/search?utf8=✓&q=soup
It builds because it's javascript, but then at runtime it wouldn't work. Perhaps the patch needs to be updated.

@lethalman evolution-data-server won't build (missing dependencies) if Google auth is enabled. I had a look at the missing dependencies and had the impression they were present. I decided to go on and come back later.
@lethalman ok for gnome-maps and libsoup. It's on my todo list.

@lethalman @edolstra I've a question about harfbuzz and it's use in gnome3.20's sushi. To make sushi compile, I have to patch its files (see commit 6d0a864):
+  postConfigure = ''
+    substituteInPlace src/libsushi/sushi-font-widget.h \
+        --replace "<hb-ft.h>" "<harfbuzz/hb-ft.h>"
+    substituteInPlace src/libsushi/sushi-font-widget.c \
+        --replace "<hb-glib.h>" "<harfbuzz/hb-glib.h>"
+  '';

Is that an upstream bug? How can it even build for them?

Strange. It should work if they passed "correct" cflags.
$ nix-shell -I nixpkgs=. -p pkgconfig -p harfbuzz
$ pkg-config --cflags harfbuzz
-I/nix/store/bvx3xyrcpfdf8rl00kg75cwkcwcardaq-harfbuzz-1.1.2/include/harfbuzz

@lethalman why do some gnome packages, like tracker, embed the definition of their src whereas most others have a src.nix autogenerated?

That sushi version doesn't depend on harfbuzz at all, they fixed it on master though: https://github.com/GNOME/sushi/blame/master/configure.ac#L58

@DamienCassou because I didn't transition all the packages to the external src.nix. You can do it.

@lethalman the dependency is not specified in the configure script, but the C files depend on harfbuzz header files.

@DamienCassou yes what I said, it's fixed in their master branch.

build is finally finished! I will see if I can switch my system and use it now.

if someone wants to try re-enabling gnome3_20.empathy, that would be great. I give up.

Lethalman:

we must be sure that the nixos-rebuild output does not depend on gtk 3.18 or any of the gnome 3.18 dependencies

how can I do that please?

@DamienCassou nix-build nixos/tests/gnome3-gdm.nix, then check with nix-store -qR result

Let's keep google auth disabled of e-d-s for now, it requires webkitgtk and json-glib. I'd like to keep less dependencies on webkitgtk. We can re-enable it if someone needs it in the future.

I'm not quite sure what e-d-s is, but I probably do...

@jgillich e-d-s = evolution-data-server

Nitpick: it's typically better to avoid force-pushing on branches in NixOS/nixpkgs.

@vcunat sorry about that. I'm still in a learning phase and I can't do things without doing mistakes. Can I please continue force pushing this time? Next time, I will keep work in my remote.

I think it's not really a problem, at least until someone tries to collaborate on that branch or base stuff on it. (Neither seems likely to happen within a few days.)

is it required to update gtkmm from 3.18 to 3.20 right now? I have the impression this triggers a lot of additional required changes (including patching inkscape).

It's likely not required for anything. We were often leaving *mm lagging behind gnome versions.

$ nix-build nixos/tests/gnome3-gdm.nix
machine# [   41.188876] dhclient[668]: DHCPDISCOVER on eth1 to <IP_ADDRESS> port 67 interval 13
machine: exit status 0
machine: making screenshot ‘screen.png’
machine: sending monitor command: screendump /nix/store/gic3cph6zzczj9n56cn0m0wrwwn1s1q3-vm-test-run-gnome3-gdm/screen.png.ppm
collecting coverage data
machine: running command: test -e /sys/kernel/debug/gcov
machine: exit status 1
syncing
machine: running command: sync
machine: exit status 0
cleaning up
killing machine (pid 66)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/tmp/nix-build-vm-test-run-gnome3-gdm.drv-0/vde1.ctl': Directory not empty
/nix/store/gic3cph6zzczj9n56cn0m0wrwwn1s1q3-vm-test-run-gnome3-gdm

$ echo $?
1

It built fine for me, but it's a different hash: /nix/store/q30zc7r80qxb54gzdf50gak2wci2bshj-vm-test-run-gnome3-gdm

Some nixos derivations (documenation?) capture whole subdirectories of your nixpkgs, so if one has stray files in there, they will change the hashes.

@vcunat did a git clean -xdf and the result is the same.

I've added the nixos/tests/gnome3_20.nix test. It fails to run gnome shell apparently.

@lethalman this is beyond my knowledge and available time right now. Are you ok to carry on this work? I know I only did the simple things but I hope it helps a bit.

The libgit2 update (shared by all packages) broke the older version of libgit2-glib in gnome-3.18. I suppose we should keep these two close to each other, either both outside gnome3 or both in. I expect it should be easiest to keep them shared by all, similarly to glib itself. @lethalman: what do you think?
Otherwise I can't see any significant regressions, so we could merge and continue fixing gnome-3.20 on master.

@vcunat thanks for testing. I was a bit afraid of the patch to Inkscape I had to do. I hope there won't be other such regressions. As you suggested earlier, we could also let *mm packages behind.

I haven't really tested myself yet – I just looked at Hydra.

Sure I can jump on this, no problem. Will fix stuff, as soon as gnome-shell works I'll merge.

Squashed all the gnome related things.

Still haven't found the reason why gnome 3.20 doesn't start.

@lethalman what about updating gdm to 3.20 as well?

@DamienCassou I've tried 3.16 and 3.18 in the past of course, but failed. Currently I can't even run gnome 3.20, it doesn't start gnome-shell, so trying to use 3.20 is out of question for me. If you want to try it, feel free to but be aware it's a mess.

@lethalman ok ok :-). I just thought maybe the problems with gnome 3.20 could be solved with a newer gdm, but I know nothing about that

@DamienCassou yes quite possible. Every gdm version is a different beast. But I'm more worried about gnome 3.20 not working at all :)

Based on your gnome-3.18 testing, I picked a few of your commits to staging in 4d37411b35046b4 (without -x as you tend to change the history) – notably gtk3 and glib major updates.

Please remember to "rebase" once in a while, so that changes introduced in GNOME 3.18 files, since this branch was started, are not lost. For instance, I had to re-apply ca717d0d654c11cc59622123251e79bb9ec7142d because it was lost during 3.16 -> 3.18.

rebased on current unstable 6d16979, also added the test to the release so we can see it on hydra

Today I finally had some time to track down the issue. It was this bug that has been fixed with gnome-session 3.20.1: https://github.com/GNOME/gnome-session/commit/890a797a2b6c26e752fa74a09d9521bea913c621

On June 2, 2016 1:43:30 PM GMT+02:00, Luca Bruno<EMAIL_ADDRESS>wrote:

Today I finally had some time to track down the issue. It was this bug
that has been fixed with gnome-session 3.20.1:
https://github.com/GNOME/gnome-session/commit/890a797a2b6c26e752fa74a09d9521bea913c621

Thank you Luca. I'm far away from any computer but will try when I come back.
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

@vcunat merged, I think we can delete the gnome-3.20 jobset.

I tried to delete the jobset and since then hydra.nixos.org stopped working completely :-( I'm really sorry if I triggered it. /cc @edolstra


Integration with strawberry (graphql queries) and pydastic (elastic search).

First Check

[X] I added a very descriptive title to this issue.
[X] I used the GitHub search to find a similar issue and didn't find it.
[X] I searched the SQLModel documentation, with the integrated search.
[X] I already searched in Google "How to X in SQLModel" and didn't find any information.
[X] I already read and followed all the tutorial in the docs and didn't find an answer.
[X] I already checked if it is not related to SQLModel but to Pydantic.
[X] I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

[X] I commit to help with one of those options 👆

Example Code
-

Description
As per title. Would be great if we had one model that could work with pydastic and strawberry queries. Maybe I'm naïve....
Wanted Solution
I would want execute strawberry and pydastic queries/insertions on a SQLModel.
Wanted Code
-

Alternatives
Asking the same in the the strawberry and pydastic repos.
Creating a new project to incorporate all 3....
Operating System
Windows
Operating System Details
Windows 11 home
SQLModel Version
0.0.8
Python Version
3.10
Additional Context
https://github.com/strawberry-graphql/strawberry/discussions/1183
Might be some code/additional context here.

from sqlmodel import SQLModel, Field
from strawberry import schema, ID
Define your SQLModel
class Item(SQLModel, table=True):
id: int = Field(default=None, primary_key=True)
name: str
Define Pydantic model for validation
class ItemPydantic(BaseModel):
name: str
Define Strawberry GraphQL schema
@schema
class ItemSchema:
id: ID
name: str
Define Strawberry GraphQL query
@strawberry.type
class Query:
@strawberry.field
def get_item(self, id: int) -> ItemSchema:
item = get_item_by_id(id)  # Implement this function
return ItemSchema(id=item.id, name=item.name)
Define Strawberry GraphQL mutation
@strawberry.type
class Mutation:
@strawberry.mutation
def create_item(self, name: str) -> ItemSchema:
item = create_item(name)  # Implement this function
return ItemSchema(id=item.id, name=item.name)
Create Strawberry GraphQL⬤


[Handles] batch msa {needs larger convo}

@wilwade and @saraswatpuneet lets sync up with @enddynayn on this one in open week meeting


Symmetry in indices of sparse data

We could simply give the list of equivalent indices obtained by permutations. This would imply the automatic creation of a variable nperm containing the number of equivalent permutations and perm, the list of permutations.
The default is nperm=1 and perm=[(1,2,3,4)] (for 4 index data). We can encode the potential sign change in the sign of the first element.
For example, for two-e integrals:
int32_t perm[8][4] = {
  1, 2, 3, 4,
  3, 2, 1, 4,
  1, 4, 3, 2,
  3, 4, 1, 2,
  2, 1, 4, 3,
  2, 3, 4, 1,
  4, 1, 2, 3,
  4, 3, 2, 1 };

trexio_write_ao_2e_int_eri_perm(trexio_file, 8, perm);

We could also store the most common predefined values:
int32_t trexio_4_index_1_perm[1][4] = {
  1, 2, 3, 4 };

int32_t trexio_6_index_1_perm[1][6] = {
  1, 2, 3, 4, 5, 6 };

int32_t trexio_4_index_4_perm_real[4][4] = {
  1, 2, 3, 4,
  3, 2, 1, 4,
  1, 4, 3, 2,
  3, 4, 1, 2 };

int32_t trexio_4_index_4_perm_cplx[4][4] = {
  1, 2, 3, 4,
  -3, 2, 1, 4,
  -1, 4, 3, 2,
  3, 4, 1, 2 };

int32_t trexio_4_index_8_perm_real[8][4] = {
  1, 2, 3, 4,
  3, 2, 1, 4,
  1, 4, 3, 2,
  3, 4, 1, 2,
  2, 1, 4, 3,
  2, 3, 4, 1,
  4, 1, 2, 3,
  4, 3, 2, 1 };

int32_t trexio_4_index_8_perm_cplx[8][4] = {
  1, 2, 3, 4,
  -3, 2, 1, 4,
  -1, 4, 3, 2,
  3, 4, 1, 2,
  2, 1, 4, 3,
  -2, 3, 4, 1,
  -4, 1, 2, 3,
  4, 3, 2, 1 };

Looks good to me but I would replace nperm with perm_num in order to be consistent with other dimensioning variables. Perhaps @plopezrios or @michalhapka could comment on this from the user point of view.


[PartEditor] Prepare document file path members

This will prepare document file path members and set filename in UI.
ONE-vscode-DCO-1.0-Signed-off-by: SaeHie Park<EMAIL_ADDRESS>

for #641, from draft #647
UI difference before: upper, after: lower


Revert replays actions from reverted transaction. This test exposes it.

Revert skips the first action with the specified ID, but it mistakenly replays all subsequent actions with ID. Need to filter those out when creating newOptimist.
I'll let you handle your src - my JS isn't as sweet.

Thanks for the bug report.  I ended up rewriting the entire data model when I realised how horribly broken it was.  Your test case is included as "real world example 2" in the newly updated code.


If the source is openshift-route then we fetch the credentials from the secret we requested from cloud credentials operator.

If the source is openshift-route then we get the credentials from the secret we requested from cloud credentials operator.
This fixes https://issues.redhat.com/browse/CFE-135

@Miciah PTAL

@arjunrn  PTAL

/lgtm

@miheer we think this may have caused https://bugzilla.redhat.com/show_bug.cgi?id=2019001
possible we will have to open a revert PR until this can be resolved as it's blocking some things which are blocking some important things. :)


Updated MAINTAINERS.md format.

Coming from https://github.com/opensearch-project/.github/issues/121, updated MAINTAINERS.md to match opensearch-project recommended format.

Looks like some CI had failed, please do take a look or at least open an issue.
https://github.com/opensearch-project/anomaly-detection/pull/771/checks?check_run_id=10465752997


Added comments and exporting bindings

Added a feature export_bindings that saves the resulting bindings.rs file, and so that we can version control it.
The feature ensures that we don't use it on crates.io, but still can keep track of what is emitted from bindgen from the flecs source.
Used the aforementioned feature to engineer this: We retain comments from the flecs source, and we use callbacks to make sure that they don't result in warnings. Trimmed, removed brackets that may insinuate intra-links, and also formatted hyperlinks properly.

For instance, one commit I just pushed does this:
    let bindings = bindings
        .allowlist_file("flecs.c")
        .allowlist_file("flecs.h")
        .generate()
        .expect("Unable to generate bindings");

Which aims to remove all C-system-header stuff from the bindings. Their effect on the bindings is now visible here in the PR.

Comments from the build.rs
	// We generate bindings to an actual source file so that we get better IDE integration
	// Sadly to publish on crates.io we cannot write outside the OUT_DIR revisit this later.
	// let out_path = PathBuf::from(env::var("CARGO_MANIFEST_DIR").unwrap());
	// bindings
	// 	.write_to_file(out_path.join("src/bindings.rs"))
	// 	.expect("Couldn't write bindings!");

I've updated the description, and amended the purpose of this PR.


expose location-overrides for modifiers

This PR changes the modifier schema in the catalog API so that the location_overrides field is exposed.
We need location_overrides to get the correct modifier pricing at a location.

Hi @tom-thorne,
Unfortunately because our SDKs are generated we cannot merge pull requests directly onto this repo, and we have to make the changes in our code generator. We do appreciate the work you did here though in terms of laying out / calling out the issue! I'm happy to say that we have brought in support for location overrides in SDK version 27.0.0. Check it out!
Thanks again!


Is there any doc about the file format?

Tantivy is great. We're developing a ES-like(much simpler and specific to our needs) system based on tantivy. Currently, we're doing some optimization and we need some info about the format of various tantivy files like .idx and .term. Is there any doc available or should we read some source code? Thanks!

I'm glad you like tantivy!
I'm afraid there are no proper documentation of the .idx and the .term format.
If you go through the trouble of reverse engineering it, I would really appreciate if you could share the documentation.
Did you need to expose some new API?

@marsqing Also please let us know if your project progresses, your findings and share if you end up having something in production!

Closing in favour of #981


Added hxWindowColorMode

Added hxWindowColorMode to the engine, allowing for changing the window header, border, and title text!
run haxelib install hxWindowColorMode 0.2.0 to add the library to your haxelibs.
The class is pre-added to HScript.hx so you can freely use it without having to use import hxwindowmode.WindowColorMode;
You can also use lua to call these functions using callMethodFromClass like:
callMethodFromClass("hxwindowmode.WindowColorMode", "setWindowColorMode", {true, true});

i think this is a pretty neat misc addition to the engine


Installing workflowgen

Expected behavior
Install workflowgen
Actual behavior
Unknown Blob
Information about the Issue
Steps to reproduce the behavior

...just pull workflowgen docker image
...

This is a Windows Container image only - Please see the documentation for this image and the requirements.
To learn more about Windows Containers, please see this post:
https://blog.docker.com/2016/09/build-your-first-docker-windows-server-container/


chore(main): release 3.2.1

:robot: I have created a release beep boop
3.2.1 (2023-08-16)
Bug Fixes

Add documentation and type definitions for the new event.client.* fields (#625) (a6f557b)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/fastly/js-compute-runtime/releases/tag/v3.2.1 :sunflower:


Possibility to be strict while validating JSON responses with more keys than defined in spec

Hi,
I'm trying out connexion, and even with logging level = DEBUG I can see it's not validating response data. Looking through the source code I don't see in master where it actually does any validation of responses.
Has this been implemented?
thanks

When you make the call to app.add_api() you need to pass the argument validate_responses=True

I am passing that parameter:
connexion_app.add_api(
'swagger.yaml',
resolver=class_resolver,
validate_responses=True)

The validation is a bit limited right now.  Try changing a type in your swagger doc and see if it fails validation (e.g., int to float or string or such).

Thanks for the fast response.
one example I'm testing is this simple schema. The customer.get_customer method is returning a dictionary with many more keys than just 'id', but no exception is raised.
I am using connexion==1.0.84
  /customer/{customer_id}:
    get:
      summary: Get Customer By ID
      description: Returns details about a customer
      operationId: customer.get_customer
      produces:
        - application/json
      parameters:
        - in: path
          name: customer_id
          description: Customer ID
          required: true
          type: integer
          format: int64
      responses:
        "200":
          description: successful operation
          schema:
            $ref: "#/definitions/Customer"

definitions:
  Customer:
    type: object
    properties:
      id:
        type: integer
        format: int64

No problem.
Yeah, that kind of validation isn't yet in connexion as far as I know.  I discovered that myself a few weeks ago.  It's on my todo list to add.  I believe data types are the only real response validation at the moment.  Missing or extra return values aren't caught yet.

great, thanks for the info, I won't worry about it right now.

Extra keys in objects are not covered. It should throw an error if you mare missing a required field in a object though.
If we are thinking of adding that kind of validation (more keys than defined) I would recommend to add an option to make the validation be strict about that or not.

@rafaelcaricio @dfeinzeig Hi there, wondering if this issue is on the way to resolution or if we ought to keep it open?

@LappleApple it could stay open as a suggestion to someone looking to work on something in Connexion.

Good news, everyone!
The current version of connexion can already raise validation errors if any unexpected key is present.
Following from the example above, with an API so defined:
definitions:
  Customer:
    type: object
    additionalProperties: false
    properties:
      id:
        type: integer
        format: int64

Code that returns a Customer object so defined:
{'id': 42, 'password': 's3cure', 'name': 'charlie'}
Yields:
  validation error: Additional properties are not allowed (u'password', u'name' were unexpected)
I'd update the docs, and close the bug :)

(Option number 2 is to add a strictly_validate_responses param)

@invernizzi-at-google thanks for pointing out. Closing this issue.


WFLY-15550 move Weld subsystem to Jakarta namespace variant

JIRA link - https://issues.redhat.com/browse/WFLY-15550

Started this as a draft because there are some open questions that I asked in a separate email discussion. I will update this PR once I get the answer.

The failures so far don't seem related, it's:

Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.3.0:wget (ts.config-as.configure-infinispan-server) on project wildfly-ts-integ-clustering: IO Error

I have no idea what's the cause since the URL it attempts to download is OK.

This PR now contains changes for Weld subsystem as well as wildfly-weld-jpa module, both as a separate commit.

@bstansberry this PR should now be reviewable

@manovotn re the wget problem, I've seen it elsewhere now and started a discussion -- https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/wget.20failures.20in.20testsuite

The PR status block doesn't reflect this but I reran the two failed jobs and they passed.

Thanks @manovotn!

My pleasure.
Thanks for making such detailed guide for this @bstansberry :-)


General fixes

@Tom94 Just want to confirm once more that you're okay with this change. I'm against exposing UpdateSubTree so much like this, my proposal is the following:

I'll be leaving merging this in your hands otherwise.

Keep in mind we also need to be able to block the initial UpdateSubTree.

We will also need a way to reset variables at the start of a new update loop, so would have to expose an extra method UpdateBeforeChildren at very least

Also I'm not sure of the naming of this container, but it's ambiguous at best. Again, would need to be accompanied by good xmldoc.

This is the accompanying code which would use the proposed class:

Feels a bit round-about-y byt I'm neutral.

I don't really like the name UpdateBeforeChildren, because Update is already before children. I do agree with smoogipooo, though, that making UpdateSubTree public isn't good.
One thing that could be done is to not iterate updates until RequiresExtraUpdates == false, but until our time is equal or further than the parent time (inside DetachedUpdateContainer). That would remove the need for UpdateBeforeChildren, and might also remove the need for some other redundant state tracking.

Let's go with this for now.


Add resources for MATLAB

Hello @saptarshihalder I would like to work on this issue !

Hey @saptarshihalder ,  i would like to contribute to the issue

I have a video about that form Freecodecamp
https://youtu.be/7f50sQYjNRA


Online

How can I run it online? I've tried Colab, Gradio, etc...I know there's a online demo, but it is suspended, and I can't use it and I can't wait, also, my PC doesnt meet the requirements, so if someone can provide the code, give it!

We will  resume the service as soon as possible. Thank you for your attention.


arg processing / take images from stdin write images to stdout

cheers.

Wow Awesome work @davehorner 🤯
Let me find some time this weekend to review it, thanks!

Btw, there is a large overlap between process_dynamic_image and process_image that bothers me a bit. I suggest putting the overlap part into a function. WDYT?
Personally, I'm fine with the overall code change. If there is no changes from you, I'm gonna merge it and get involved in enhancing the code.

I agree, I quickly pulled out a function and didn't spend any more time to refactor.  give me a little time here and I'll get the latest code up.

i added another pull request. you are welcome to merge whatever you like.  thanks!


When will the dataset be released

Thanks to the author's contribution, I also interested in this field and hope to see the dataset earlier.

Thank you for your interest in our paper. We are doing some final revisions of our dataset and will release it soon when it is ready.

Can you provide estimate date for release of the dataset?

Thanks to the author's contribution, When will the CI-AVSR dataset be released?

When will the CI-AVSR dataset be released

Hi all, the dataset will be released this month.
We didn't release it before because we applied the SemEval 2023 and the result will be notified soon. Whether accepted or not, we will release the data.
Thank you for your interest!

Hi, are there any updates?

Hi, the first version of the dataset has been released, please check the README page. Thanks!


Minor help updates

closes #56

Nice catches with these updates.

@jyppy caught them so a team effort!


State Colors not rendering

The states all appear white with black text in light mode  and all balck with white text in dark mode in the Theme Builder UI

roblem content]()

[link to p

Proposed Solution

I believe that this was fixed by https://github.com/discoverfinancial/a11y-theme-builder-sdk/commit/c7ef62577a604b7abfce522023612cc6e4314d4f in the sdk.  Please pull latest and verify whether this issue still exists for you or not.

This has been resolved.


Updated the README

I think this looks better

hey I'm a comment

commenting during a test

I think this looks ok so far

checking out the code


Upup Integrations take too long to process when big files are submitted

Can you provide more details ?

Ah my apologies!
So, take any file from google drive or from onedrive that is pretty large (say 100MBs or higher). You will notice that it seems like nothing is loading / happening but give it some time and your file will finally appear on the UpUp selection.

@AminDhouib yes we need to add loader when uploading

Status on this issue? @bassem97  @MohamedBechirMejri

Actually that depends on your upload speed

screen-capture.webm

Yup! Precisely. We added the progress bar which pretty much "fixes" the concern. Closing the issue. Thanks @bassem97 just wanted to confirm.


security: refactor koinu conversion functions

a number of issues were present with regards to the previous implementation of koinu conversion. floating point types are prone to failure depending on what system architecture they are built on. this was unacceptable in consideration to it being one of, if not the most mission critical function of our library.
to mitigate, i've added 2 completely refactored conversion utilities that convert between uint64_t and char* in preparation for replacement in our high level api functions. this feature is provided as a 'convenience' feature to facilitate easier understanding for new developers approaching libdogecoin and dogecoin in general, who may be unfamiliar with koinu. in the future though, i think conversion from uint64_t should fall on other developers once there are more matured high level language wrappers available.
i've prepared removal of dependence on long doubles primarily with 2 shim functions, koinu_to_coins_str and coins_to_koinu_str, which demonstrate usuability in the unit test found in test/koinu_tests.c. the following changes are reflective of these rules as defined by the SEI CERT C coding standard and of work found from the branch xanimo/0.1-dev-koinu-refactor:
INT18-C. Evaluate integer expressions in a larger size before
comparing or assigning to that size
INT30-C. Ensure that unsigned integer operations do not wrap
INT31-C. Ensure that integer conversions do not result in lost
or misinterpreted data
ERR02-C. Avoid in-band error indicators
ERR30-C. Take care when reading errno
ERR33-C. Detect and handle standard library errors
MSC21-C. Use robust loop termination conditions
-remove extraneous code from utils.c with regards to conversion utilities
-refactor coins_to_koinu_str to handle mixed length mantissas
-remove dependence on strdup in coins_to_koinu_str
-move koinu conversion utilities/tests to dedicated files
-split up conditionals in validate_conversion to evaluate bounds checks individually in order to allow more flexibility.
-allow omission of char* types in validate_conversion to allow stand alone bounds checking for uint64_t types.
-add CONVERSION_UNDERFLOW in validation_conversion to prevent returning true when a negative number in a string is converted.
-add more stress unit tests to test/koinu_tests.c to attempt breaking the conversion functions.

Merging changes from ull/ll to string for universal koinu precision and no need to worry about rounding.


Test that dropping/delaying/reordering datagrams is correctly handled in QUIC

We introduce a BIO filter that simulates network noise by randomly dropping/delaying/reordering datagrams and test that a QUIC connection can be established and data exchanged reliably.
We use test_random() to generate the randomness so any test failures can be reliably reproduced.

This pull request is ready to merge

Pushed. Thanks.


Change "OK" button to "Reset" in Hard Reset dialog

Resolves #1211
Before:

After:

You may want to add multi language support

Added the translations using Google Translate @ewpatton.

@conorshipp
Please notice that the translation you choose 重启(Restart) may not good as 重置(Reset) here.
@p4ssw0rd Please help me to look at this

@ColinTree I actually typed "Reset" and copied the Chinese translation I was given. I just reversed the translations (Chinese to English) and it returned "Reboot" 😕
I just tried your suggestion and it does return "Reset".

@conorshipp I am willing to accept @ColinTree's proposed change.

I've updated the translation @ewpatton @ColinTree

@conershipp That would be great😀

I think this is ready to be merged/reviewed @ewpatton I did update the translation.

@AppInventorWorkerBee ok to test

All tests passed. +1 Verified.


Budget fiddling

A bunch of exploration of minor issues discovered in budget calibration, ostensibly about #1020 but also involving some tracy markup, some internal cleanup, machinery to allow excluding the overwhelming VM instantiation cost center, and some attempts at setting budget costs more from first principles.

@jayz22 on second thought I reverted the hard-wired constant measurement overhead; it breaks tests and does so in a way that suggests why it's wrong: it breaks the implicit contract that "costs are reflected by the cost schedule only". Maybe we can just give everything in the cost schedule slightly higher constant terms to cover the measurement overhead.


Change serialization/deserialization in communication with cairo native

We can change it to CBOR instead of json

Just want to lay off some thoughts:
Do we need a data format at all? We don't store the inputs or outputs directly
Maybe we should consider a only in-memory data format, that's represented solely by rust structs/enums, we should have a enum that holds all possible value types, and those value types are specific to cairo/sierra, for example, this is a possible list of types:
pub enum SierraValue {
    Felt252(..),
    Uint{u8...512}(..),
    GasBuiltin(u128),
    SystemBuiltin(..),
    Array(Vec<SierraValue>),
    Struct(Vec<SierraValue>),
    ...
}

You get the idea.
I think the problem lies in not using a domain specific format and relying on something like json, etc.

Actually, you don't need neither JSON nor CBOR. Having no real format should be fine. You just need something that implements DeserializeSeed and Serialize. The examples use JSON because it's human-readable and convenient, but note that it's listed as an optional dependency, only used in the CLI binaries, but not in the library itself.
@edg-l's approach reminds me of serde_json::Value. It would work but I'm not sure it's really better than using the json!() macro, which generates a serde_json::Value.
If we know the signature of a method at compile-time there's really nothing stopping us from doing something like this, without depending on any specific format:
struct EntryPointArgs {
    arg0: i32,
    arg1: Felt252,
}

impl Serialize for EntryPointArgs {
    fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
    where
        S: Serializer,
    {
        serializer.serialize_i32(self.arg0)?;
        self.arg1.serialize(serializer)?;

        todo!()
    }
}

It's better than using the json macro because the struct/enum i mentioned is specific for this aproach, json is generic, we also don't need the overhead of parsing json.
I don't think its realistic to expect to know the signature of the methods of cairo programs we want to run at compile time (given the expect use of cairo-native)

This was already fixed by not using serde at all.


Update Set-OrganizationConfig.md

The DisablePlusAddressInRecipients parameter has the wrong state for when the value is set to true or false. This is a double negative so when set to false it's enabled.

Docs Build status updates of commit 1aec006:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Set-OrganizationConfig.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Column Resizing

How can we set columns in VxGrid to be resizable.

As of now, the only way to resize the columns is through the 'Manage Columns' popup/modal. We dont have a drag-n-drop based resizer directly on thr grid to aid us due to perf considerations.


Object key type should be forced to be a string (index signature parameter)

Bug Report

🔎 Search Terms

Object key type, index signature parameter type
🕗 Version & Regression Information

This is the behavior in every version I tried, and I believe it should act differently

⏯ Playground Link

Playground link with relevant code
💻 Code

const a: {[prop: number]: number} = {};

a[1] = 123;

for (const i in a) {
    console.log(a, a[i], typeof i);
}

🙁 Actual behavior

I'm allowed to set the prop key to type number, but it is actually a string when tested
🙂 Expected behavior

It should not allow me to use number as the type for the key properties as it automatically converts to string anyways which could create confusion

This is intentional and has been the behavior for... ever? Changing this would be a massive breaking change.

I'm aware that this has been the way it was forever, hence: This is the behavior in every version I tried, and I believe it should act differently.
I understand this will be a breaking change, I don't expect this to be changed in a minor version bump, but it's a dangerous design decision since it sets the wrong expectation for the type of the properties, especially in a language where types are supposed to be more controllable.
I can see that looping through the properties shows the property as a string and trying to compare using === will indicate that it will never match since it's a string, but something like + can cause unexpected bugs and there are other situations where this might cause potentially difficult to find bugs.

Sure, but it's not a bug.  It's a design decision you don't agree with.  You might consider changing this from a bug report to a feature suggestion.   Perhaps #43041 is close to what you're asking for, and also see #32047.

I don't understand what's being suggested here. Where specifically do you want an error, or do you just disagree with the existence of numeric index signatures in general?

I disagree with the ability to set index type to number for an object type when in reality, once the type of the index is checked, it's actually a string. Since that's the behaviour of JS, I don't expect TS to make number indexes on object types a possibility, so I think it would make more sense to set expectations correctly and not allow the code sample I gave to work (since it's actually a lie).
const a: {[prop: number]: number} = {};

a[1] = 123;

for (const i in a) {
    console.log(a, a[i], typeof i);
}

The output of the console.log is:
{
  "1": 123
},  123,  "string"

I'll change this to a feature request, should I edit the original post, add a new comment or completely start a new issue?

This is the intended behavior. Numeric index signatures mean that when you index an object by a key by a string which was produced from the coercion of a number, a particular property type is produced. It doesn't imply that a different storage format is being used at runtime.
We are not accepting feature requests to remove language constructs.

That's great in theory, but due to the way types work in the rest of the language, it isn't immediately obvious. There's also this:
keyof typeof a which returns a number type (which makes sense when considering you have to use a number type for the index, but since the index itself becomes a string, it gives the wrong impression).
It would be nicer to have a more concise way to specify a type as a string representation of a number which would make it more understandable than specifying the type as a number when it's a string and it would probably give people that are looking for such a feature a bit more control and consistency.
I was aware of this for a while, but I've seen people make this mistake and it's easy to understand why, it's simply not concise enough.

The type system is largely constructed of such artificial distinctions - at runtime there's no difference between an empty string[] and and empty number[], yet the type semantics of them are different. We need some concept of a numeric key to meaningfully describe how arrays work, which is numeric index signatures.
keyof typeof a is a fully-consistent description of what types x may have for the expression a[x].

I'm well aware that at runtime the types don't truly matter since you could save whatever type you want into whatever variable. The point remains that number is not a fitting type for this and a better type might need to be created to address this.
Some kind of numeric string type should be created or at least a type that can represent this in a more accurate way.

So should I make a new feature request to create a new type for this purpose instead of using number?

@rosenbergd if you like; please keep backcompat in mind if you want it to be seriously considered

Just linking this to the new issue created
#44649


Linting and Typing fixes

This PR is a draft - meant to show the kind of changes I've implemented.
What it includes:

Provide a thorough update on the lining setup and fix ALL ESlint issues.
thorough fixes to the typescript and typescript setup of the project
myriad cleanups and fixes of issues discovered via automated code inspection
Up-to-date testing setup
initial tests.

If you guys are happy with the changes happening in this PR, I will finish fixing all typescript issues and scaffold a few more tests for Vue components and other elements. My goal is to give you guys an excellent base to convert the entire vue side of the project to typescript by resolving the annoying vue-related issues (it's been like this for the past five years with vue and TS) and also giving you a few excellent examples of how tests can be added to the entire project.
please let me know if you want me to proceed and finish this PR.

Thank you for submitting this draft PR. It's great to see the progress you've made so far. Please continue to complete the TypeScript issues and enhance the test coverage as you've outlined. We look forward to seeing the complete PR and appreciate your efforts to streamline and modernize our codebase. As there are many files involved in the changes, we may conduct more comprehensive testing of your changes after you submit the complete PR to prevent any unexpected situations. Thank you again for your contribution. To facilitate communication, this message has been translated by AI.

great @umodoc - i will close this PR for now, and make sure to resolve all conflicts before opening it again after I finish fixing the issues remaining. I will also sync my branch.


send ofFloatPixels with 4bytes per channel

Hi,
is there an easy way to send a 4bytes per channel color image? I noticed if I send a ofFloatImage (4 channels / 4byte per channel) it gets converted to a ofImage with only 1 bytes per channel.
I studied the source code but have a hard time to understand how and if it's possible to archive what I am trying to do.

I'm not sure that NDI itself supports sending an image of 4 bytes per channel.
If you found any in official SDK document, let me know which section.
If it's possible, you can directly configure NDIlib_video_frame_v2_t and send it via ofxNDISendVideo or ofxNDISendVideoAsync.

All right, thanks for taking your time and looking into it. I checked the documentation but couldn't find anything which made sense to me. I guess for now I need to look for a different solution. I was asking for ofFloatImage as I was trying stream a stereo camera pointcloud via ndi.
... might make sense to let that issue open, just in case others will face the same/similar situation?!

... might make sense to let that issue open, just in case others will face the same/similar situation?!

no.
It's an "Issue" page here and it was not an issue of this addon, and people can find closed issues.
thanks,


Custom Bundle Identifier delete main java files

Version used:
    "react": "16.0.0",
    "react-native": "0.51.0"
    "react-native-version": "2.2.2",

What happened:

In folder android/app/src/main/java/my/custom/bundleIdentifier there were 2 files MainActivity.java and MainApplication.java
Run react-native-version newName -b my.custom.bundleIdentifier

Observation:
After react-native-rename finished, the two above file are deleted. So when I create an apk from the app and install to device, app always crashes when I try to open. No error message, no bug report (I use Bugsnag to track bugs and crash exceptions)

same issue

This is a real bug....There's no fix until now

yes, same error.

it just two files. just copy the older ones and paste with the newer package name corrected on both file. Easy and works fine.

Duplicate of #55


Error with Glimmer 2 [Ember 2.9.0 bata 3]

Hey there!
We are getting an error when using this addon with Ember 2.9.0 beta 3 where Glimmer 2 is the new rendering engine.
// bootstrap-datetimepicker.js:2254

Uncaught TypeError: input.size is not a function

The stack trace points to this block:
            input = element.find(options.datepickerInput);
            if (input.size() === 0) {
                input = element.find('input');
            } else if (!input.is('input')) {
                throw new Error('CSS class "' + options.datepickerInput + '" cannot be applied to non input element');
            }

Would be wonderful if you could take a look on this. Thanks.

This is also happening in Ember 2.8.1.

The problem is that the size function was removed in jquery 3.0

It seems that this is a problem in upstream related to jquery version. More info: https://github.com/Eonasdan/bootstrap-datetimepicker/issues/1684

Confirmed that updating the ember-bootstrap-datetimepicker version to 4.17.42 in the package.json file fixes the issue

Should be fixed on master, https://github.com/plusacht/ember-bootstrap-datetimepicker/blob/master/blueprints/ember-bootstrap-datetimepicker/index.js#L6


Add delegated authority. Widget state may be broken

Description
When user create "Add delegated authority operation" the state of widget may be broken

🍿Example🍿
https://github.com/novasamatech/nova-spektr/assets/40560660/a0658994-9774-4b1a-bb62-369d52d7a801

Steps to Reproduce

Add a few delegated authorities one by one

Actual Behavior
Regular proxy widget is stuck and can't be open
Environment
https://github.com/novasamatech/nova-spektr/commit/683af3e412c17bea7781600b5882375b01b7f632

Status verification: ✅


Revert "github tools: add fossa license scanning (#927)"

This reverts commit b565d7395b338faada40e3b28cd4ce85989beb99.
Revert fossa scan until we can figure out the failure https://github.com/netlify/cli/runs/806674169?check_suite_focus=true

@emilyzhang can you help with this issue?

@erezrokah this should fix it: https://github.com/netlify/cli/pull/956

Thanks @emilyzhang !


Integrate API

Start the test server and integrate the proposed information into your application.

npm run server

b9aea64161fdbc90b82c3a4240aeed77c1a0717f


I didn't  discover List of devices in Android 12 and Higher versions. Is there any issue in plugin.

I didn't  discover devices in Android 12 and Higher versions. Is there any issue in plugin.

try swapping the device_info package to device_info_plus. it worked for me. Apparently device_info is no longer maintained and i think something changed between android versions that made it so device_info causes android 12+ to no longer be able to browse. If this doesnt work i would try experimenting with permissions. I am 90% sure its device_info being outdated but i can be wrong. In my testing i used a moto X4 and a OnePlus Nord CE 3 Lite 5G. I added a bunch of perms but il need to filter them out later so i would recommend getting the perms from the example and any that might be needed for android 12+ like bluetooth scan advertise and connect


fix issues with {getFrameData,submitFrame} must be called within a VRDisplay.requestAnimationFrame callback. (fixes issue #65); fix JS errors Screen position out of view frustum in Chrome Canary (fixes issue #64)

Fix #64
Fix #65
seems to work well. feedback to approach, including possible edge cases I've missed, welcome.
tested with HTC VIVE on Windows 10 in both Chrome Canary and Firefox Nightly.

@cvan Tested with FF and Chrome Canary, looks to be working well. The only thing that broke is that we're starting out in the ground.

thanks for testing. any ideas how to fix? did you check + build on master to compare?

I pulled, rebased, but I'm still getting these conflicts according to GitHub. hmm… I'll have to look in the morning (my morning).

@delapuente @caseyyee: ignoring the Build/ mess, I just want to make sure that these changes (really just to Assets/WebGLTemplates/WebVR/webvr.js and Build/webvr.js) run smoothly for you and with no discernible regressions.
thanks for reviewing and testing, you both :+1:

No problem Chris, if you can not solve the issues, I will rebase it. I'm having problems with my VIVE right now and cannot wake the base stations up so I can not test it.

This is inevitable:

@cvan Tested with FF and Chrome Canary, looks to be working well. The only thing that broke is that we're starting out in the ground.

Now, when not presenting, we are not updating the camera matrices. For me, it makes perfect sense since we are returning the control to Unity's camera system. If this is the desired behaviour, we must also reset the effect of setting worldToCameraMatrix by calling Camera#ResetWorldToCameraMatrix.html on all the cameras of the WebVR rigging. It can be done when handling the End message sent from JavaScript to Unity.

@cvan working as expected on my side. Solve the issues and grant me access to your repo if you need help with the rebasing. Nice work. These are all valuable steps towards #104

@delapuente with the polyfill, it should still update (this should be the old version still?)
If we replaced it with the newer one, then yeah.  It won't hit that code path.

@delapuente with the polyfill, it should still update (this should be the old version still?)

Even with the polyfill, the execution will never hit that code path (notice the test condition and the early return)

@cvan, I've discarded your changes on Build/ to ease the rebase. I'll regenerate them and push to master once this is merged. Please, address the changes and remember to not commit the changes on Build. Thank you so much, let's fix two bugs for the price of one!


Store - overview page - GRAPHQL api operations not visible

This is cannot reproduce in 3.0.0-m35


[csolution] Allow to specify the output artifact cmse library for secure projects

Describe The Problem To Be Solved
When a secure project specifies non-secure callable entry points it must generated a cmse library for the non-secure projects along side a header file with the corresponding function prototypes.
Proposal
Extension of the node:
output
adding a type cmse-lib

OK, I suggest to work on #826 and for now keep the name: <project-name>_CMSE_Lib.o.  OK for everyone?

In #826 the suggestion to access a CMSE Library is with a dedicated access sequence:
- group: CMSE Library
      files:
       - file: $cmse-lib(CM33s)$

IMHO this removes the need to rename the output name.
I personally believe we should rework output and provide the following:
output:
  - base-name: <base-file-name> # for all output artifacts
  - type: hex   # generate a HEX file
  - type: bin   # generate a BIN file
     offset:      # potential options for BIN file generation

Replaced by #894 and #895


[SPARK-25483][TEST] Refactor UnsafeArrayDataBenchmark to use main method

What changes were proposed in this pull request?
Refactor UnsafeArrayDataBenchmark to use main method.
Generate benchmark result:
SPARK_GENERATE_BENCHMARK_FILES=1 build/sbt "sql/test:runMain org.apache.spark.sql.execution.benchmark.UnsafeArrayDataBenchmark"

How was this patch tested?
manual tests

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3297/
Test PASSed.

Test build #96351 has started for PR 22491 at commit 5bb5f08.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3370/
Test PASSed.

Test build #96463 has started for PR 22491 at commit 1f492ee.

Test build #96463 has finished for PR 22491 at commit 1f492ee.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96463/
Test FAILed.

retest this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3374/
Test PASSed.

Test build #96467 has started for PR 22491 at commit 1f492ee.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3375/
Test PASSed.

Test build #96467 has finished for PR 22491 at commit 1f492ee.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96467/
Test FAILed.

retest this please

Test build #96468 has started for PR 22491 at commit 1f492ee.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3377/
Test PASSed.

Test build #96468 has finished for PR 22491 at commit 1f492ee.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96468/
Test PASSed.

Merged build finished. Test PASSed.

@dongjoon-hyun This refactor is ready to go. Thanks.

Thank you for pinging me, @wangyum .

Retest this please.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3634/
Test PASSed.

Test build #96862 has started for PR 22491 at commit 1f492ee.

Test build #96862 has finished for PR 22491 at commit 1f492ee.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96862/
Test FAILed.

Test build #96878 has started for PR 22491 at commit 5c819fb.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3642/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3646/
Test PASSed.

Test build #96883 has started for PR 22491 at commit 4b69423.

Test build #96878 has finished for PR 22491 at commit 5c819fb.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96878/
Test PASSed.

Test build #96883 has finished for PR 22491 at commit 4b69423.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96883/
Test PASSed.

Merged to master.

Thank you, @wangyum !


bug resolve related to threading in macos

Description
Bug resolve attempt related to threading in macOS
Issue :

Attempts to fix #(368)
Type of change

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

Checklist:

[x] I have performed a self-review of my own code.
[x] I have added tests/screenshots (if any) that prove my fix is effective or that my feature works.

I do not know why line endings are broken, I can't solve it from Github UI.

I made a commit here with all the changes: https://github.com/metacall/core/commit/8bb69332f12fcf3ece420dc020e39c4d0dbb3606


Enter in form always closes mwc-dialog, despite workarounds

Describe the bug
Sometimes users want to prevent <mwc-dialog> from firing primary action on Enter keypresses.
For example, if the form contains a, dropdown, if the user selects a dropdown item with enter, it closes the dialog instead of only closing the dropdown
Workaround attempts:

slot the action buttons, but use event.preventDefault() - dialog still closes
don't slot the action buttons - empty hard-coded 54px high footer
slot the cancel button but not the action button, and use stacked - buttons not aligned
Conclusion: there's no way to use mwc-dialog 0.20 with selects, dropdowns, or other components for which Enter key is a legitimate but non-closing user action

the dialog content's padding is hard coded, so my only recourse is to use css transforms to move the non-slotted button, and I'll still get excess whitespace
The one partial workaround I found was to disable the primary action button when the form is invalid
But this only works if all the form fields are required
Case:
form has three fields,

text, required
select, required
select, optional
A. user types text, then hits Enter
=> Dialog does not close
B. user hits Tab, Space, DownArrow, DownArrow, Enter
=> dialog closes, but user could not select from the second select field

To Reproduce
Steps to reproduce the behavior:

Add a dropdown-like component to a dialog's body
open the dialog
open the dropdown
focus an item with arrow keys
select the item with Enter key

Expected behavior
Dropdown closes, but dialog remains open

I have the described problem with mwc-textarea's.
I think this issue is related https://github.com/material-components/material-components-web-components/issues/629
If I interpret the closing comment by @e111077 correctly, there will be no change to this behavior.

I have the described problem with mwc-textarea's.
I think this issue is related https://github.com/material-components/material-components-web-components/issues/629
If I interpret the closing comment by @e111077 correctly, there will be no change to this behavior.

This should be possible now with the get/setSuppressDefaultPressSelector() MDC foundation methods that were added a while back. We should be able to expose these via a property on the web component for custom use cases where the default press (enter) needs to be suppressed for specific needs.
Additionally, we can update the default selector to be more compatible with MWC elements so that <mwc-textarea> and menu-based <mwc-list-item> do not trigger the default press.

This should be possible now with the get/setSuppressDefaultPressSelector() MDC foundation methods that were added a while back. We should be able to expose these via a property on the web component for custom use cases where the default press (enter) needs to be suppressed for specific needs.
Additionally, we can update the default selector to be more compatible with MWC elements so that <mwc-textarea> and menu-based <mwc-list-item> do not trigger the default press.

I'll take this up now

I'll take this up now

Fixed in https://github.com/material-components/material-components-web-components/pull/2073

Fixed in https://github.com/material-components/material-components-web-components/pull/2073


Line 64 Asterisk

It's intended.  It is there due to the fact that I can't validate the storage requirements (nor RAM).  For additional details, see #21.


Update 'Fund Account' (Buy) design and text

Please update the Fund Account screen with the following changes:

Secondary button style on Buy:
https://www.figma.com/file/VupGh90FJtT0dcBj2Sh7bb/📏Spec?node-id=1856%3A12455

Update illustration, text, add component to choose from more than one option, and add legal disclaimer:
https://www.figma.com/file/VupGh90FJtT0dcBj2Sh7bb/📏Spec?node-id=1856%3A12439

Thank you!

This is outdated, so closing the issue.


Fix typo and formatting issues in types-and-variables.md

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot


Implement OTP support

This:

fixes #77
upgrades from packages.config -> new csproj style references. VS made it seem like I needed to do this to get things to work
adds support for OTP Code generation via the generate-totp-code comamnd. - It supports otpauth and totp style keys like gopass.

This works with all of my accounts, I tested half a dozen or so.
TODO:

unit tests
check on the roslyn linters that I removed from the csproj (can we get those back with nuget, are they not needed, etc)

But I wanted to go ahead and send it out since it is working for me.

This fixes #77 by the way.

note to self, this crashes if the secret entry looks like this:
totp: 4DJZ XXXX YYYY AUEQ

unclear why, but need to add a test case for it, etc.

Thank you so much for taking my suggestion into consideration guys! Very much appreciated! The build seems to have failed for not finding a file, what was the problem? It seemed like everything was ready.


Correction to code sample

Summary
Should this none-deterministic call from Finalizer use Dispose(false) as it does for base class and none-derived classes?

Hi @definedrisk - great catch. I believe that you're correct that this should in fact be passing false not true. @bartonjs can you confirm quick?
class DerivedClassWithFinalizer : BaseClassWithFinalizer
{
    // To detect redundant calls
    bool _disposed = false;

    ~DerivedClassWithFinalizer() => this.Dispose(true); // This should be false, right? 😬

    // Protected implementation of Dispose pattern.
    protected override void Dispose(bool disposing)
    {
        if (_disposed)
        {
            return;
        }

        if (disposing)
        {
            // TODO: dispose managed state (managed objects).
        }

        // TODO: free unmanaged resources (unmanaged objects) and override a finalizer below.
        // TODO: set large fields to null.
        _disposed = true;

        // Call the base class implementation.
        base.Dispose(disposing);
    }
}

Reference


Fix maven warnings

When running the plugin on Maven 3.9+ the following warnings are printed out:
-Dmaven.plugin.validation=VERBOSE
[WARNING]  * io.github.floverfelt:find-and-replace-maven-plugin:1.1.0
...
[WARNING]   Plugin issue(s):
[WARNING]    * Plugin is a Maven 2.x plugin, which will be not supported in Maven 4.x
[WARNING]    * Plugin mixes multiple Maven versions: [3.8.1, 2.2.1]
[WARNING]    * Plugin should declare these Maven artifacts in `provided` scope: [org.apache.maven:maven-plugin-api:3.8.1, org.apache.maven:maven-artifact:3.8.1, org.apache.maven:maven-model:3.8.1]
[WARNING]    * Plugin depends on plexus-container-default, which is EOL

Fixed


Clarify improper definition in spec, including figure illustrating torsions

The current definition of improper torsion of improper torsions appears to not be fully explicit in specifying exactly which torsions the improper functional form is applied to. A diagram would also help substantially, since the ordering of atoms is not obvious (e.g. atom index 2 is the central atom).

Slightly off topic but I love @lilyminium 's table of impropers, https://github.com/lilyminium/improper_orders.


glob pattern does not work in "ignoreWorkspaces" option

Hello
Using glob expression does not work in ignoreWorkspaces option, for example, ignoreWorkspaces: ["packages/*"]
Example of a basic monorepo: https://github.com/eltonio450/knip-glob
In this monorepo:
const config = {
    ignoreWorkspaces: ["packages/*"]
}

export default config

outputs:

whereas:
const config = {
    ignoreWorkspaces: ["packages/1"]
}

export default config

outputs:

Not sure if it's a feature or a bug, but as we had to add this option when migrating to v2, it's kinda to add all the packages manually in this option
Thank you !

Now I see unfortunately the documentation indicates wildcards are allowed in ignoreWorkspaces, while they're not. So it's a feature request after all.

"it's not", meaning it's not meant to be for now ?
thank you !

Yeah, it's not meant to be today :)

:rocket: This issue has been resolved in v2.17.2. See Release 2.17.2 for release notes.

whoa, that was fast, thanks !


docker fails at the npm install step

Description or steps to reproduce the problem
make start
Expected Behavior
Get access to the web app.
Actual Behavior
I get a node error:
 ~/f/WebClient   public  make start
./bin/crun-node npm install --unsafe-perm --loglevel warn --no-bin-links
Resolving node version...
 Please update to<EMAIL_ADDRESS>as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated<EMAIL_ADDRESS>Deprecated, use jstransformer
npm ERR! Linux 4.4.0-45-generic
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--unsafe-perm" "--loglevel" "warn" "--no-bin-links"
npm ERR! node v5.11.1
npm ERR! npm  v3.8.6

npm ERR! Maximum call stack size exceeded
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /home/pierre/f/WebClient/npm-debug.log
Makefile:8: recipe for target 'npm-install' failed
make: *** [npm-install] Error 1

Here are more details from the npm-debug.log:
70003 silly build<EMAIL_ADDRESS>70004 verbose stack RangeError: Maximum call stack size exceeded
70004 verbose stack     at emitThree (events.js:110:13)
70004 verbose stack     at emit (events.js:188:7)
70004 verbose stack     at null.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npmlog/node_modules/are-we-there-yet/tracker-group.js:23:18)
70004 verbose stack     at emitThree (events.js:110:13)
70004 verbose stack     at emit (events.js:188:7)
70004 verbose stack     at null.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npmlog/node_modules/are-we-there-yet/tracker-group.js:23:18)
70004 verbose stack     at emitThree (events.js:110:13)
70004 verbose stack     at emit (events.js:188:7)
70004 verbose stack     at null.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npmlog/node_modules/are-we-there-yet/tracker-group.js:23:18)
70004 verbose stack     at emitThree (events.js:110:13)
70004 verbose stack     at emit (events.js:188:7)
70005 verbose cwd /home/pierre/f/WebClient
70006 error Linux 4.4.0-45-generic
70007 error argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--unsafe-perm" "--loglevel" "warn" "--no-bin-links"
70008 error node v5.11.1
70009 error npm  v3.8.6
70010 error Maximum call stack size exceeded
70011 error If you need help, you may report this error at:
70011 error     <https://github.com/npm/npm/issues>
70012 verbose exit [ 1, true ]

should this be closed? There's no Makefile anymore and the code requires node >=6 now.


WebComponentsReady will not fire without the wjs import

WebComponentsReady event does not fire if there are no imports to webcomponentsjs-lite or webcomponentsjs full versions. How do we handle the ready event on evergreen browsers like chrome?

Check out https://gist.github.com/ebidel/1d5ede1e35b6f426a2a7#file-wcr_lazyload-html-L20-L27

Great, thanks!

On a second note, this seems to be fired way earlier than I want it to fire, it fires at the right time if I include wcjs lite version... any idea?

The timing of the native apis and the polyfills will be different. What do you mean by "at right time"?

@ebidel The timing on the polyfill seems to fire correctly. I am trying to add a loading animation on the index page, I am not able to access the loading container to hide it if I use the approach you provided. It fires way too early before the DOM is ready. But if I use the lite version, I am able to access the loading container on WebComponentsReady.

You'll have to post a repro.

 window.addEventListener('WebComponentsReady', () =>{
                console.log('WebComponentsReady')
            });

doens't fire in Chome but Safari


mention Dart syntax highlight for next release

Thank you, I somehow thought I did this already, but apparently I didn't.
Note that the supported syntax is listed in two places, would be nice to always add it to both.
The other is here: https://github.com/planet42/Laika/blob/master/docs/src/01-about-laika/01-features.md#content-organization

Note that the supported syntax is listed in two places,

Thanks, done.


Fix to allow streaming of PUT data in the HTTP_EVENT_HEADERS_SENT callback

Setting the state to HTTP_STATE_REQ_COMPLETE_HEADER prior to calling the HTTP_EVENT_HEADERS_SENT callback allows streaming of PUT data in the callback.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hello @kfurge-egi
Sorry for the late response.
Is there any test that we can add for this to test the correct functionality?
Also can you please sign the CLA agreement?
Thanks!

Merged with https://github.com/espressif/esp-idf/commit/90be9cc3e8e499e54f070079401ba2ae1052f486


Colab error - Object detection model customization guide - No module named 'keras.src.engine'

Running the standard colab get No module named 'keras.src.engine'

found a fix in the setup step
From
!pip install  mediapipe-model-maker
to
!pip install 'keras<3.0.0' mediapipe-model-maker


How to load 32-experts Swin-transformer-moe on a 2-GPU machine.

Hi,
I have downloaded the checkpoint for a 32-expert Swin-Transformer-MOE. However, the checkpoints are dependent sub-checkpoints distributed across different ranks (32 ranks). I want to load these sub-checkpoints and fine-tune the model on a 2-GPU machine.
To do this, should I gather the sub-checkpoints into a single checkpoint? I attempted to use the script from gather.py, but it did not work. Could you help me understand what went wrong?
Additionally, I checked the original code and found that the condition "if k.endswith('._num_global_experts')" is returning false. Is this due to the format of the Swin-Transformer-MOE checkpoint? I'm quite confused about this.
Thank you for your assistance!

If I load the Swin-Transformer-MOE checkpoint directly, an error occurs."
Or, to be a bit more detailed :    load_pretrained(config, model_without_ddp, logger)
[rank0]:   File "/ai_home/data/private/ywx/Swin-Transformer/utils_moe.py", line 217, in load_pretrained
[rank0]:     msg = model.load_state_dict(state_dict, strict=False)
[rank0]:   File "/opt/conda/envs/tutel/lib/python3.8/site-packages/torch/nn/modules/module.py", line 2215, in load_state_dict
[rank0]:     raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(
[rank0]: RuntimeError: Error(s) in loading state_dict for SwinTransformerMoE:
[rank0]:        size mismatch for layers.2.blocks.1.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.1.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.1.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.1.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 384]) from checkpoint, the shape in current model is torch.Size([32, 384]).
[rank0]:        size mismatch for layers.2.blocks.3.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.3.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.3.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.3.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 384]) from checkpoint, the shape in current model is torch.Size([32, 384]).
[rank0]:        size mismatch for layers.2.blocks.5.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.5.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.5.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.5.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 384]) from checkpoint, the shape in current model is torch.Size([32, 384]).
[rank0]:        size mismatch for layers.2.blocks.7.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.7.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.7.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.7.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 384]) from checkpoint, the shape in current model is torch.Size([32, 384]).
[rank0]:        size mismatch for layers.2.blocks.9.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.9.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.9.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.9.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 384]) from checkpoint, the shape in current model is torch.Size([32, 384]).
[rank0]:        size mismatch for layers.2.blocks.11.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.11.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.11.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.11.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 384]) from checkpoint, the shape in current model is torch.Size([32, 384]).
[rank0]:        size mismatch for layers.2.blocks.13.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.13.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.13.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.13.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 384]) from checkpoint, the shape in current model is torch.Size([32, 384]).
[rank0]:        size mismatch for layers.2.blocks.15.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.15.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.15.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.15.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 384]) from checkpoint, the shape in current model is torch.Size([32, 384]).
[rank0]:        size mismatch for layers.2.blocks.17.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.17.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.17.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.17.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 384]) from checkpoint, the shape in current model is torch.Size([32, 384]).
[rank0]:        size mismatch for layers.3.blocks.1.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 3072, 768]) from checkpoint, the shape in current model is torch.Size([32, 3072, 768]).
[rank0]:        size mismatch for layers.3.blocks.1.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 3072, 768]) from checkpoint, the shape in current model is torch.Size([32, 3072, 768]).
[rank0]:        size mismatch for layers.3.blocks.1.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 3072]) from checkpoint, the shape in current model is torch.Size([32, 3072]).
[rank0]:        size mismatch for layers.3.blocks.1.mlp._moe_layer.experts.batched_fc2_bias: copying a param with shape torch.Size([1, 1, 768]) from checkpoint, the shape in current model is torch.Size([32, 768]).

The pretrained checkpoint maybe too old which was designed by a legacy Tutel version. Can you provide the checkpoint link you use, and SWIN command to load it?

The pretrained checkpoint may be old which was compatible with a legacy Tutel version. Can you provide the checkpoint link you use, and SWIN command to load it if possible?

Hi, I have loaded the checkpoint from (https://github.com/SwinTransformer/storage/releases/download/v2.0.2/swin_moe_small_patch4_window12_192_32expert_32gpu_22k.zip).
I used the command: torchrun --nproc_per_node=1 --nnode=1 --master_port 12347  main_moe.py --cfg configs/swinmoe/swin_moe_small_patch4_window12_192_32expert_32gpu_1k 128.yaml --data-path imagenet --batch-size 128 --pretrained swin_moe_small_patch4_window12_192_32expert_32gpu_22k/swin_moe_small_patch4_window12_192_32expert_32gpu_22k.pth
(For "swin_moe_small_patch4_window12_192_32expert_32gpu_1k", I used imagenet 1k to fintuning, and I only modify the dataset)
If you have any suggestions or improvements, please let me know. Thank you!

I just merged a PR (https://github.com/microsoft/tutel/pull/249) to ensure checkpoint compatible with legacy format.
Can you upgrade tutel installation, and follow this New Steps to convert the SWIN checkpoints and see if it works?

I just merged a PR (#249) to ensure checkpoint compatible with legacy format.
Can you upgrade tutel installation, and follow this New Steps to convert the SWIN checkpoints and see if it works?

Thank you for your modifications! I upgraded the Tutel installation and followed the steps to merge the checkpoint. However, the issue still persists. Upon printing the merged checkpoint, I noticed a mismatch with the model.
erorr:
[rank0]:        size mismatch for layers.2.blocks.1.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.1.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.1.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.3.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.3.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.3.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.5.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.5.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.5.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.7.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.7.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.7.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.9.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.9.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.9.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.11.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.11.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.11.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.13.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.13.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.13.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.15.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.15.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.15.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.2.blocks.17.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.17.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 1536, 384]) from checkpoint, the shape in current model is torch.Size([32, 1536, 384]).
[rank0]:        size mismatch for layers.2.blocks.17.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 1536]) from checkpoint, the shape in current model is torch.Size([32, 1536]).
[rank0]:        size mismatch for layers.3.blocks.1.mlp._moe_layer.experts.batched_fc1_w: copying a param with shape torch.Size([1, 3072, 768]) from checkpoint, the shape in current model is torch.Size([32, 3072, 768]).
[rank0]:        size mismatch for layers.3.blocks.1.mlp._moe_layer.experts.batched_fc2_w: copying a param with shape torch.Size([1, 3072, 768]) from checkpoint, the shape in current model is torch.Size([32, 3072, 768]).
[rank0]:        size mismatch for layers.3.blocks.1.mlp._moe_layer.experts.batched_fc1_bias: copying a param with shape torch.Size([1, 1, 3072]) from checkpoint, the shape in current model is torch.Size([32, 3072]).
Therefore, it seems that the dimensions being merged may be incorrect, and not all the parameters of the experts have been combined properly？

I think you may not follow the instructions correctly. The examples in tutorial should exactly work for your zip file. You should get a new checkpoint folders containing 3 files in total. Please check if your new checkpoint folder corresponding with file list below:
$ ls -ls new_swin_moe_small_for_2_gpus/
total 2121952
202872 -rw-r--r-- 1 root root 207739264 Oct 28 04:20 swin_moe_small_patch4_window12_192_32expert_32gpu_22k.pth.master
959540 -rw-r--r-- 1 root root 982561440 Oct 28 04:19 swin_moe_small_patch4_window12_192_32expert_32gpu_22k.pth.rank0
959540 -rw-r--r-- 1 root root 982561440 Oct 28 04:19 swin_moe_small_patch4_window12_192_32expert_32gpu_22k.pth.rank1

May I know if the problem is solved?

Feel free to let us know if the issue is still unsolved.

Thank you very much. The issue has been resolved.


[Feature Request] Precision Dance Pad config

A Precision Dance Pad 4 panel pad has 6 buttons.  I mapped them using this string:
0300000009d200000115000000000000,Precision Dance Pad,platform:Windows,a:b3,b:b2,x:b4,y:b5,back:b0,start:b1,
My hope is this will be useful to someone else.

Thanks for the submission, I'll add it to our database.


Allow specifying viewport sizes as relative, e.g. 80%

From the code:
        css(viewport, {
            width: self.options.viewport.width + 'px',
            height: self.options.viewport.height + 'px'
        });

It would be super helpful if the width and height could be specified as percents of the boundary size, or perhaps have them exposed via CSS directly.

Looks like we do it for boundary ... just not viewport ... that wouldn't be too hard of a change to make.
See: https://github.com/Foliotek/Croppie/blob/master/croppie.js#L348

Any updates this? I would like to have the viewport the same size as the boundary (100%)

@Hesesses Doesn't appear to be any updates.  I would be open to a pull request, as it'd be a simple change to make.

@thedustinsmith Could you please tell me, How to make this specific change?
I want my editor to be responsive on every mobile device.

@alimemonzx You can create a fork and try try copying the behavior we use for the boundary:
https://github.com/Foliotek/Croppie/blob/master/croppie.js#L385
... and make the viewport do something similar:
https://github.com/Foliotek/Croppie/blob/master/croppie.js#L394
This would allow you to do:
var croppie = new Croppie(element, {
  viewport: { width: '80%', height: '80%' },
  boundary: { width: '100%', height: '100%' },
  //etc
});

That will at least configure the UI how I imagine you'd like it.  When it comes to grabbing the result - I don't know what will happen, but feel free to experiment.


Fails on Vercel (using PlanetScale/MySQL)

First, thanks @mikecao for making Umami! It's awesome!
I'm having an issue when deploying to Vercel.
Here's the error I get after trying to login:
ERROR	PrismaClientInitializationError3 [PrismaClientInitializationError]: Can't reach database server at `<host_redacted>`:`3306`Please make sure your database server is running at `<host_redacted>`:`3306`.
    at cb (/var/task/node_modules/@prisma/client/runtime/index.js:36380:17)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async __WEBPACK_DEFAULT_EXPORT__ (/var/task/.next/server/pages/api/auth/login.js:115:21)
    at async Object.apiResolver (/var/task/node_modules/next/dist/server/api-utils.js:102:9)
    at async Server.handleApiRequest (/var/task/node_modules/next/dist/server/next-server.js:1017:9)
    at async Object.fn (/var/task/node_modules/next/dist/server/next-server.js:904:37)
    at async Router.execute (/var/task/node_modules/next/dist/server/router.js:210:32)
    at async Server.run (/var/task/node_modules/next/dist/server/next-server.js:1088:29)
    at async Server.handleRequest (/var/task/node_modules/next/dist/server/next-server.js:304:20)
    at async Server.<anonymous> (/var/task/___next_launcher.js:32:9) {  clientVersion: '2.29.1',  errorCode: undefined}

Here's the weird part - the same database connection works when running the client locally.
Increasing the Prisma connect_timeout in DATABASE_URL didn't work.
Observation: I'm using PlanetScale (https://planetscale.com) and therefore:

had to remove foreign key constraints from the schema.
needed to add ?sslcert=ca-certificates.crt to DATABASE_URL (where ca-certificates.crt is in ./prisma).

I have no idea why it works locally (with remote db) but not on Vercel.
I know this is not an issue with Umami itself, but hoping someone can help, and that when resolved this can help others!

The problem happens because the file ca-certificates.crt doesn't exist in the environment of the deployed cloud functions.
It's working after following the solution in this comment: https://github.com/prisma/prisma/issues/1673#issuecomment-647107891

Hi, can you please guide me how can I setup umami with planetscale?
I have tried multiple times with no success.

Would love it if you could make a guide about how you solved it @danaugrs. 👍🏻

@danaugrs Feel free to add a guide to the website, https://github.com/mikecao/umami.is

Hi, here is my workaround to make it work with PlanetScale. Hope it helps.

Clone the umami repo to local
Create .env file
Add DATABASE_URL and HASH_SALT value into .env (like the documentation told)
Update schema.mysql.prisma (see why)

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["referentialIntegrity"]
}

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
  referentialIntegrity = "prisma"
}

Add seed to package.json

"prisma": {
  "seed": "node prisma/seed.js"
},

Run npx prisma db push --schema=./prisma/schema.mysql.prisma to sync schema
Run npx prisma db seed to push default data to PlanetScale
Verify if data is seeded npx prisma studio --schema=./prisma/schema.mysql.prisma
Done

Hey @mikecao and everyone, I just setup a fresh Umami instance with PlanetScale + Vercel and created a guide.
Here's the PR: https://github.com/mikecao/umami.is/pull/51
These are the instructions for PlanetScale:

Fork the https://github.com/mikecao/umami project to your GitHub account.
Create a database on PlanetScale called umami-db and get its connection string (Hint: select "Prisma" from the "Connect with" menu). It should look something like this: mysql://username:password@host/umami-db?sslaccept=strict
Add DATABASE_URL and HASH_SALT (any random string) to you .env file:

DATABASE_URL=mysql://username:password@host/umami-db?sslaccept=strict
HASH_SALT=any-random-string

Open schema.mysql.sql and delete all lines starting with foreign key and make sure to delete the dangling commas.
Download the PlanetScale CLI and authenticate with pscale auth login.
Create the tables by running the following command on the root of the project: pscale shell umami-db main < sql/schema.mysql.sql.
You should now be able to build and start Umami (npm run build followed by npm start).
Follow the Getting started guide starting from the Login step and be sure to change the default password.

Notes:

I did not have to modify schema.mysql.prisma (as suggested by @culee above) to get things to work, but it might be beneficial.
The original problem I encountered when deploying to Vercel (with PlanetScale) didn't manifest itself, and the corresponding solution I previously used (https://github.com/prisma/prisma/issues/1673#issuecomment-647107891) was unnecessary.

Hope this helps!

@danaugrs thanks for updating the running on planetscale doc, but when I tried to follow line for line, it doesn't work out of the box.
I followed @culee 's post with initial suggestions and it was reaffirmed in planetscale's prisma documentation
By updating a couple lines in schema.prisma, you don't have to touch any foreign key lines in sql/schema.mysql.sql
The original project leverages yarn and although there is no package-lock.json i reinstalled yarn just to make sure i had the same dependencies via yarn.lock as the main repo.
After running yarn build, planetscale db needs to be updated and one could run npx prisma db push
why prisma db push?
Then you can run yarn start to view your local instance
Happy to update the guide to reflect this or defer to @danaugrs as the original author


Remove all genproto.sh files

This change is towards the goal of moving the generation of the generated protobuf files to the Dockerfile and not checking them into the repository.
These files are not used by anything.
Changes
Remove all genproto.sh files

LGTM and I have only one note (not a blocker).
Removing the genproto.sh files will not impact the services, but it may impact on ppl trying to build/compile the project locally.
Hence, it would be good to have a README, explaining how to compile the proto files per service.
Something like @mic-max have done in this PR already: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/300001bb6f895bffca5910eccaa7569285308f8e/src/recommendationservice/README.md

By build/compile the project locally I guess you also mean without using docker, right? for example, they run go build and it complains about the missing files
In follow-up PRs we could include this instruction in the service READMEs like you linked the example where I did so 👍


Item header score

Fixes #136
Added the score ring to the item header.
The score is round down to the nearest integer to avoid a really long floating point number.

Codecov Report

Merging #140 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #140   +/-   ##
=======================================
  Coverage   43.20%   43.20%
=======================================
  Files          85       85
  Lines        1155     1155
  Branches      197      197
=======================================
  Hits          499      499
  Misses        630      630
  Partials       26       26

Continue to review full report at Codecov.

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


Remove Protobuf Dependency

We announced in the Forum that the NNS dapp will remove the protobuf dependency.
We would like to do the same in the IC app of the Ledger.
Could you prepare a release without any of the protobuf code?
I would appreciate it if there could be extra checks to make sure we didn't forget any support for Candid. Could you give us the list of transactions that are not supported in Candid. As far as I know, only Merge Maturity should not be supported because it was deprecated.
Thanks!

:link: zboto Link

@lmuntaner
current candid transactions supported by the ledger application:

candid_manageneuron
candid_listneurons
candid_updatenodeprovider
candid_transfer
candid_icrc_transfer

the supported pb transactions that would be removed:

send_request
manage_neuron
list_neurons
claim_neurons

we could remove protobuf support or maybe add a compilation flag todisable/enable it.

We will remove protobuf support. No need to consider a solution with a flag.