Translation flow

There is currently no process set up to edit labels (english or other languages).
~Secondly most of the texts that are there in the file is placeholder like "Fill in some content here" or even worse is missing and hence just show as filter.hostKey.description~ removing placeholder values has an issue of its own https://github.com/gbif/hosted-portals/issues/134

We are able to do so by forking this repository and making pull requests though, no?

We could (not this repo though, but this monorepo https://github.com/gbif/gbif-web/tree/master/packages/react-components), but it isn't the best way to get people involved. We have used Crowdin for GBIF.org and other projects. It works well is my impression. And has a lot of nice features you wouldn't get with pull requests (such as an easy way to discuss and share context). And get machine suggestions. And get previews for messageformat with variables in them. And perhaps most importantly, no broken syntax and scary process for those less tech savy

Thinking about how best to reuse enumeration value translations (Preserved Specimen etc), which are already translated into several languages for GBIF.org, and need to be consistent between these.

We could add the additional languages (Samoan etc) to the GBIF.org CrowdIn project, with instructions only to translate the "enums" folder
We could take the enumeration translation files at HP component build time from the GBIF portal project, i.e. https://github.com/gbif/portal16/tree/master/locales/translations/fr/enums

The rest of the HP UI (Search, Basis of Record) could be a second CrowdIn project — CrowdIn should make suggestions where the text is already translated for GBIF.org, but it will required the translator to review and accept those suggestions.
[We could add the hosted portal translation keys to the GBIF.org translation project in CrowdIn (it seems to be possible to connect two Git repositories), but I think this would be confusing to the existing GBIF.org translators.)
(For some of these enumerations, the best place to put translations would be the XML definitions of the vocabulary/thesaurus. That would make them reusable in the IPT and by anyone else.)

The flow we have for GBIF.org - I imagine we do something similar

Some web developer (e.g. me) write their best attempt (I refer to it as danglish)

I'm open to someone else correcting these through pull requests or even just in issues starting today. This way you can influence the next step ;)

This is then translated into proper english by the GBIF secretariat comms team

My impression is that GBIF communications would prefer to control this step

The corrected english is the source that translators see as the source for other languages.

This is up to the community and are discussed and edited openly in Crowdin.

I've updated this issue to be translation flow specific. As we already have another issue for removing/replacing placeholder texts. The two tasks are independent and fixing placeholder texts should really be done before any translations starts

I created a pull request with English text for as many terms as I could identify.

Some thoughts on how this could/should be implemented.
@thomasstjerne and @MattBlissett do you have any thoughts on how this should be done?
Browser perspective
I can see these options:

the lib user adds a script tag pointing to one or more translation file(s) (e.g. spanish).
The lib user then refer to that when configuring the data components.
The lib user simply states some locales they want to support and the component knows where to fetch a translation file.

Both approaches could work, but the second allow us to load them as needed. This could matter for performance if the site has many translations. (say one translation is 50kb and then load 10 of them)
Common to both is that it loads a single file. Our translation library expects a single json with all strings so loading them as one seems the simplest and should perform better as well.
Where to translate this project
I too think it makes sense to have this project alongside the "gbif.org -ui" Crowdin project (and its english counter part). The intention is that the two will align over time, and secondly all the enumerations are already in that project.
Managing the translations
I find it easier to work with multiple files than one huge. And secondly the existing enum translations from the "gbif.org" project is individual files. So we need a to stitch them together. I imagine a build step doing that.
How much should go into the browser translation file
For gbif.org we have everything as part of the translation file. E.g. all languages and all GrSciColl collection disciplines (just to mention 2 enums that are rarely used).
Instead of including everything, we could also select those that we use most frequently and load the rest from a new endpoint. E.g. /translation/languages/abk would return Abkhazian. Similar to how we load dataset titles and scientific names.
Or we could explore the option to load all the values for an enum, but not do so until they enum is used. So the GrSciColl collection disciplines will not be loaded until you visist a GrSciColl institution page.
I'm honestly not sure how to do so technically or if it is a huge task, but I like the idea to keep the core translation file smaller by focusing on the UI elements and then load enums for data presentation asynchrounsly. I imagine that this is a fairly simple thing to do.
Performance
It is easy to get worried about band with and loading a bloated translation file too much.
It might be worth remembering that the "giant" translation file for gbif.org is 150kb unzipped and 50kb zipped. The header image alone on gbif.org is 200kb and we load 1.4 mb images for our home page alone. Individual map tiles are as big as 152kb. If we can avoid blocking the first render, then perhaps we shouldn't worry about a 10kb vs 50kb translation file.

This has progressed and is now in staging. The current state is:

The library ships with english text included. We could consider removing that, and have a loader while the relevant translations load.
Any other languages is loaded on demand if the locale is provided when mounting the widget.

It does so by calling an uncached endpoint that provide the translation mapping - meaning a link to the translation file along with a hash of the content. E.g. fr: https://some.url/translations/fr.json?v=1230987243. That means that the small mapping file will be loaded on all requests, but the large translation file can be cached. And we can do so without breaking the cache for the library. The downside is that all users must fetch the translationMap when the page is loaded. The benefit is that the library and the translations can be cached individually (meaning the french users do not need to fetch everything again just because a german translation is updated).

Translations are managed as for GBIF.org - so there is one project in crowdin that is internal that translate developer english into proper english. And then there is a secondary project that use the proper english as source and translate that to all other languages.

This means that the english version must be proofread by GBIF communications before it can be translated to other languages.

The hosted portals translations live in the same Crowdin project as GBIF.org. That means that duplicate strings can be autofilled. This is useful as many terms will be the same on the hosted portals and gbif.org. Most notably all enumerations.
The hosted portals will automatically see a translated version of the data widgets corresponding to the language code they have specified for the site. It is possible to overwrite the code in the sites _data/languages.yml.

Thank you @MortenHofft, we will be moving forward with the translations in the Crowdin project.

yes. You can upload translations to Crowdin. If you find a source and format it, then there is a button to do so.
https://crowdin.com/project/gbif-portal/nl
You can see what format they should be uploaded in if you download the file first.

I recently noted that the Dutch translations I prepared are already available through https://hp-nhm-rotterdam.gbif-staging.org/nl/data.html but are not yet deployed on the portal itself https://specimens.hetnatuurhistorisch.nl/nl/data.html (I did do a new release recently, but nothing changed). Should they first be approved on crowdin or is some other action necessary?

I have to merge it into the web project and deploy it to master. So it isn't you, but me that should monitor translations more carefully. I will redeploy it now so it should be available in a 5 minutes or so

Just to make sure I am not missing anything: I did a new release recently, but nothing changed. On crowdin https://crowdin.com/project/gbif-portal/nl the translations are still blue (not green). Please let me know if there is any other action required from our side.

I cannot see any recent changes in the Dutch translations, but I might have missed it. Could you give me an example translation that I can check? And could you specify what "nothing changed" mean: is it in staging but not in prod or does it not show anywhere?

I have not added any new translations recently, and they are still showing in staging but not in prod.

Thanks @langeveldNMR  - could you please provide an example. That will make it easier for me to find the cause.
btw there are 2 types of translations:

those that you do in crowdin - which relates to the data widgets (occurrence search).  For those to go into prod, then I have to merge the Crowdin changes and do a deployment to production. If I only deploy into staging, then it will only show in staging. That could be the reason here, except that I have done a production deployment so that is why I'm confused.
And then there are the translations you handle in your Github repo, which is for everything else (menus and, blog posts, prose etc). That will only show in production of you do a release.

It concerns the first type you list. Attached are four screenshots.
In the Dutch (NL) staging environment the data widgets are translated. However, they are not in the Dutch production environment, where they are identical to the English production environment.

ahhhh - there are no translations at all. I understood your message as "a few of the latest translations are missing". I see that I haven't added NL as a supported language in prod. That is done now. You translations are visible in your prod environment. Sorry about that - I misunderstood the problem.


feat: add fixes to api deployments and security definitions

Codecov Report
Base: 54.81% // Head: 54.81% // No change to project coverage :thumbsup:

Coverage data is based on head (65f22ad) compared to base (2e0b200).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@                   Coverage Diff                    @@
##           feat/framework-refactor     #376   +/-   ##
========================================================
  Coverage                    54.81%   54.81%
========================================================
  Files                           24       24
  Lines                         1578     1578
========================================================
  Hits                           865      865
  Misses                         649      649
  Partials                        64       64

Flag
Coverage Δ

unittests
54.81% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Why RedisClient is incomplete ?

hi,
I liked to use the "RemoveByPattern" method RedisClient class.
Unfortunately, it is not avaialble.
Do you intend to update the class soon?
Thank you.

Hi,
Could you give me some more info ? http://redis.io/commands
Tks
Vincent.

I have stored in "Redis" more keys with the same beginning.
ex: "FavoriteMenu:UserId98" and "FavoriteMenu:UserId103"
It is possible that I have to invalidate(delete) the cache of all keys that start with "FavoriteMenu."
The method "RemoveByPattern" allows me to pass it as parameter "FavoriteMenu*"
This method is present in ServiceStack.Redis but not NServiceKit.Redis.
tks
Xavier

Please do not cross post issues.
I've answer on the NServiceKit.Redis project


Recipe Modification Events

Nvm, I forgot about making recipe manipulation illegal in ADD and REMOVE

Nvm, I forgot about making recipe manipulation illegal in ADD and REMOVE

Should be done now


Notifications: $digest already in progress

Solves #250

great :) now it would be awesome to apply the same patch to modal

@maxcook I wasn't aware of any issues there. Can you open a new issue and describe the problem?


Disable pivot expand, if pivot have only one row

What version of React-Table are you using?
Your bug may already be fixed in the latest release. Run yarn upgrade react-table!
6.7.6
What bug are you experiencing, or what feature are you proposing?
need a provision to disable pivot expand, if pivot have only one row underneath, as its looks like a duplicate row entry (same as pivot level)
Use https://codesandbox.io/s/X6npLXPRW (by clicking the "Fork" button) to reproduce the issue.
Same example from the example codesandbox.io
https://codesandbox.io/s/oNY9z8xN?from-embed
What are the steps to reproduce the issue?

open the last pivot
verify the last row, Its the same as the row above
attached the image below, the row "downtown" and the expanded are the duplicate

Thanks Gary, I have a work around using Aggregated to suppress visual duplication
Aggregated: () => (

---

),

Could you please elaborate on your workaround?
We also would like to avoid expansion when it has a single item (which will be identical to the "fake" row).
We tried to block the expansion using onExpandedChange but the index received is not from the real data (rows) but from the visible "fake" rows and therefore we don't know in which real row we are (and what is its data) to decide if we should let the expansion occur or not.


Fix links that were changed in new architecture

As part of: https://github.com/hoodiehq/hoodie/issues/458#issuecomment-204634204

LGTM, don’t mind the travis error, it cannot be affected to this as this PR only updates the README


Update repositories.txt

@ArduinoBot

@ArduinoBot

Hello @beratcomputer. The automated system here only operates on open pull requests. Since your submission was already accepted and the pull request merged, the bot won't pay any more attention to this pull request.
But this human is happy to provide assistance. Was there something you needed from the bot?

I updated repo and relase new version. does It update the new one automatically?

@per1234
I renamed my library. But it has this error. I do not left anywhere old name but i have this error.
2023/11/21 08:31:50 Checking out tag: 1.0.1
2023/11/21 08:31:50 Release Acrome-SMD:1.0.1 has wrong library name, should be Acrome SMD - Arduino Library
what did i do wrong?


SPEEDHACK32.dll

I would guess the DLL in the bin folder is a compilation of the example in the src folder?
I'm injecting the DLL into a game, but it doesn't seem to take. Is detours also needed as a runtime package or something?

It's a compilation of an old example, compile it yourself w/ the detours library here: https://www.microsoft.com/en-us/download/details.aspx?id=52586


Godot aborts with stack trace on editing scene file marked as tool with a timer that frees the node

Godot version
v3.4.4.stable.official (419e713a29f20bd3351a54d1e6c4c5af7ef4b253)
System information
Linux PopOS
Issue description
Opening a scene file (in attached project) causes the following hard quit of Godot:
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v3.4.4.stable.official (419e713a29f20bd3351a54d1e6c4c5af7ef4b253)
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f6627442520] (??:0)
[2] /opt/godot/Godot() [0x2ae4157] (??:0)
[3] /opt/godot/Godot() [0x2b1cd5c] (??:0)
[4] /opt/godot/Godot() [0x1708a90] (??:0)
[5] /opt/godot/Godot() [0x170ce14] (??:0)
[6] /opt/godot/Godot() [0xb50a45] (??:0)
[7] /opt/godot/Godot() [0x2b77c39] (??:0)
[8] /opt/godot/Godot() [0x2ff86d8] (??:0)
[9] /opt/godot/Godot() [0x2b81bec] (??:0)
[10] /opt/godot/Godot() [0x9d8c5e] (??:0)
[11] /opt/godot/Godot() [0x9471ad] (??:0)
[12] /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f6627429d90] (??:0)
[13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f6627429e40] (??:0)
[14] /opt/godot/Godot() [0x95ae1e] (??:0)
-- END OF BACKTRACE --

The actual line at fault is this:
func _on_Timer_timeout() -> void:
queue_free()

My code is marked with tool.
If I remove tool or the queue_free() then it doesn't crash.

I've even deleted the entire timer from the scene and the code, but as soon as I add Timer to the project and hook it to code, it crashes again.

ooh, I've found the bug, I think.
func _on_Timer_timeout() -> void:
queue_free()
If I do not have the function queue_free() then it doesn't crash. So if I leave it as 'pass' then no crash.

@chucklepie Please upload a minimal reproduction project to make this easier to troubleshoot.

@chucklepie Please upload a minimal reproduction project to make this easier to troubleshoot.

I did, it seems to have disappeared

load_bug.zip

=================================================================
==101032==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000ebbb90 at pc 0x00000ae0ecec bp 0x7ffce615db80 sp 0x7ffce615db70
READ of size 8 at 0x617000ebbb90 thread T0
    #0 0xae0eceb in CanvasItemEditor::_build_bones_list(Node*) editor/plugins/canvas_item_editor_plugin.cpp:3930
    #1 0xae40cf6 in CanvasItemEditor::_update_bone_list() editor/plugins/canvas_item_editor_plugin.cpp:4369
    #2 0x1d2262a in MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:59
    #3 0x13789669 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:918
    #4 0x13756739 in MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) core/message_queue.cpp:241
    #5 0x137575da in MessageQueue::flush() core/message_queue.cpp:284
    #6 0x1a96a31 in Main::iteration() main/main.cpp:2341
    #7 0x1954523 in OS_X11::run() platform/x11/os_x11.cpp:4035
    #8 0x18a9ea1 in main platform/x11/godot_x11.cpp:59
    #9 0x7f4bdae2350f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #10 0x7f4bdae235c8 in __libc_start_main_impl ../csu/libc-start.c:381
    #11 0x18a9a74 in _start (/usr/bin/godots+0x18a9a74)

0x617000ebbb90 is located 16 bytes inside of 744-byte region [0x617000ebbb80,0x617000ebbe68)
freed by thread T0 here:
    #0 0x7f4bdbab4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
    #1 0x13d78069 in Memory::free_static(void*, bool) core/os/memory.cpp:168
    #2 0x1aa2c19 in void memdelete<Object>(Object*) core/os/memory.h:118
    #3 0xd7b15a7 in SceneTree::_flush_delete_queue() scene/main/scene_tree.cpp:1251
    #4 0xd79dbba in SceneTree::idle(float) scene/main/scene_tree.cpp:653
    #5 0x1a969be in Main::iteration() main/main.cpp:2337
    #6 0x1954523 in OS_X11::run() platform/x11/os_x11.cpp:4035
    #7 0x18a9ea1 in main platform/x11/godot_x11.cpp:59
    #8 0x7f4bdae2350f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

previously allocated by thread T0 here:
    #0 0x7f4bdbab4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x13d76fa3 in Memory::alloc_static(unsigned long, bool) core/os/memory.cpp:75
    #2 0x13d76eb4 in operator new(unsigned long, char const*) core/os/memory.cpp:40
    #3 0xd5a428b in Object* ClassDB::creator<Node2D>() core/class_db.h:137
    #4 0x134eb36c in ClassDB::instance(StringName const&) core/class_db.cpp:520
    #5 0x10a883e6 in SceneState::instance(SceneState::GenEditState) const scene/resources/packed_scene.cpp:182
    #6 0x10abe35b in PackedScene::instance(PackedScene::GenEditState) const scene/resources/packed_scene.cpp:1598
    #7 0x94eb38a in EditorNode::load_scene(String const&, bool, bool, bool, bool, bool) editor/editor_node.cpp:3679
    #8 0x94ee66e in EditorNode::open_request(String const&) editor/editor_node.cpp:3739
    #9 0x9ccda81 in FileSystemDock::_select_file(String const&, bool) editor/filesystem_dock.cpp:959
    #10 0x9ccf040 in FileSystemDock::_tree_activate_file() editor/filesystem_dock.cpp:978
    #11 0x1d2262a in MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:59
    #12 0x13789669 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:918
    #13 0x13794178 in Object::emit_signal(StringName const&, Variant const**, int) core/object.cpp:1230
    #14 0x13796344 in Object::emit_signal(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) core/object.cpp:1285
    #15 0xe77ac0c in Tree::_gui_input(Ref<InputEvent>) scene/gui/tree.cpp:2633
    #16 0x9d991e2 in MethodBind1<Ref<InputEvent> >::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:759
    #17 0x13784d08 in Object::call_multilevel(StringName const&, Variant const**, int) core/object.cpp:766
    #18 0x137881a5 in Object::call_multilevel(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) core/object.cpp:863
    #19 0xd8ca166 in Viewport::_gui_call_input(Control*, Ref<InputEvent> const&) scene/main/viewport.cpp:1669
    #20 0xd8d6cb8 in Viewport::_gui_input_event(Ref<InputEvent>) scene/main/viewport.cpp:1985
    #21 0xd9050ec in Viewport::input(Ref<InputEvent> const&) scene/main/viewport.cpp:2871
    #22 0xd8bcbbb in Viewport::_vp_input(Ref<InputEvent> const&) scene/main/viewport.cpp:1435
    #23 0x2a8fe01 in MethodBind1<Ref<InputEvent> const&>::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:759
    #24 0x13789669 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:918
    #25 0x13787b26 in Object::call(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) core/object.cpp:847
    #26 0xd78d443 in SceneTree::call_group_flags(unsigned int, StringName const&, StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) scene/main/scene_tree.cpp:306
    #27 0xd792fcf in SceneTree::input_event(Ref<InputEvent> const&) scene/main/scene_tree.cpp:465
    #28 0x19e19ca in InputDefault::_parse_input_event_impl(Ref<InputEvent> const&, bool) main/input_default.cpp:498
    #29 0x19ebdb5 in InputDefault::flush_buffered_events() main/input_default.cpp:725

SUMMARY: AddressSanitizer: heap-use-after-free editor/plugins/canvas_item_editor_plugin.cpp:3930 in CanvasItemEditor::_build_bones_list(Node*)

#81320 is a similar issue


Add check to determine if in browser or node

When I simplified the public API for elm-test, it caused a runtime error in the browser since the node-specific code here runs and crashes: https://github.com/deadfoxygrandpa/elm-test/issues/32
I've added some runtime checks to disable those things if it's run in the browser.

Let me know what you think, though, because the other direction I could go in is making a totally separate import for ElmTest and ElmTest.Console or something like that.

Just ran into this and let me say I really do appreciate your timeliness! I think the API is fine, just fix the bug. I'm going to pull this down locally and report back.

Confirming that it works.

Hi @laszlopandy, can you get a chance to review this soon? I can change it to the solution from @igrep if you think that's better.

:+1:

Also asking for a quick merge, as this is holding up a lot of testing and dependent packages.

Sorry guys, I didn't see this until the mention. I will merge, I just have one concern.

What's your concern?

I fixed it in a different way (without wrapping everything in isNode).
https://github.com/laszlopandy/elm-console/commit/19e686f240de46fba6cf3f187696e05da9884c44
I published it, but I have only tested it with 0.15.1. Please let me know if there are any problems with 0.16.0:
http://package.elm-lang.org/packages/laszlopandy/elm-console/1.0.3/

OK, thanks. I'll test it out in browser right now.

Yep, this works with Elm 0.16.0 in browser. Thanks!

Thanks Laszlo!


Re-include roc_std in workspace in main Cargo.toml

This inclusion used to error on windows but I don't remember the specific error.
We should see if this error still occurs and try to resolve it.
If resolution is difficult, the error should be documented better.

[ ] Once the error is resolved the serde feature can be added again when building nightly releases.

Hi I can help test on Windows 10, I just tried the following. Let me know if I missed the point on any of this or I can do anything else.

pulled latest upstream 4508a27
cargo build --features with_sound --release (to confirm the current build works of the sort of non-test build referred to in 3757 - i.e. using same command as in Earthfile:129 ?) = compiled successfully
cargo build --features with_sound serde --release (change command to include serde) = error

Found argument 'serde' which wasn't expected, or isn't valid in this context

commented out /Cargo.toml:68 # "crates/roc_std" and ran same command (trying to stop serde from being excluded?) = but get same error

cargo build --all-features --release (tried this instead?) = error below
Compiling roc_cli v0.1.0 (H:\Development\roc\crates\cli)
Compiling rustyline v9.1.1 (https://github.com/roc-lang/rustyline?rev=e74333c#e74333c0)
Compiling roc_std v0.0.1 (H:\Development\roc\crates\roc_std)
Compiling serde_bytes v0.11.6
Compiling packed_struct v0.10.0
Compiling bincode v1.3.3
Compiling darling v0.13.4
Compiling futures-executor v0.3.24
error[E0432]: unresolved imports core::ffi::CStr, core::ffi::CString
--> crates\roc_std\src\roc_str.rs:21:17
|
21 | use core::ffi::{CStr, CString};
|                 ^^^^  ^^^^^^^ no CString in ffi
|                 |
|                 no CStr in ffi
adding --verbose flag adds...
Caused by:
process didn't exit successfully: rustc --crate-name roc_std --edition=2021 crates\roc_std\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C linker-plugin-lto -C codegen-units=1 --cfg "feature=\"serde\"" --cfg "feature=\"std\"" -C metadata=6da72f51229f7359 -C extra-filename=-6da72f51229f7359 --out-dir H:\Development\roc\target\release\deps -L dependency=H:\Development\roc\target\release\deps --extern arrayvec=H:\Development\roc\target\release\deps\libarrayvec-9c84e295fbd63df3.rmeta --extern serde=H:\Development\roc\target\release\deps\libserde-e91d88ee656f5da8.rmeta --extern static_assertions=H:\Development\roc\target\release\deps\libstatic_assertions-df379069e8e3b76a.rmeta -Ctarget-cpu=native (exit code: 1)

Thanks for this detailed report @Swiftaff, I appreciate the effort :)
I'm not yet sure what's going on with "no CString in ffi" CString has moved in newer rust versions but I think it should still be there in 1.61.0.
I'll also check what happens on linux, it should definitely work there.


<IP_ADDRESS>

https://ci.appveyor.com/project/jpboyce/cb-cis-windows-2016#L1511

Resolved by 9cc4dbe


Piper training notebook doesn't start training

DEBUG:piper_train:Namespace(dataset_dir='/content/drive/MyDrive/colab/piper/Test', checkpoint_epochs=5, quality='high', resume_from_single_speaker_checkpoint=None, logger=True, enable_checkpointing=True, default_root_dir=None, gradient_clip_val=None, gradient_clip_algorithm=None, num_nodes=1, num_processes=None, devices='1', gpus=None, auto_select_gpus=False, tpu_cores=None, ipus=None, enable_progress_bar=True, overfit_batches=0.0, track_grad_norm=-1, check_val_every_n_epoch=1, fast_dev_run=False, accumulate_grad_batches=None, max_epochs=10000, min_epochs=None, max_steps=-1, min_steps=None, max_time=None, limit_train_batches=None, limit_val_batches=None, limit_test_batches=None, limit_predict_batches=None, val_check_interval=None, log_every_n_steps=1000, accelerator='gpu', strategy=None, sync_batchnorm=False, precision=32, enable_model_summary=True, weights_save_path=None, num_sanity_val_steps=2, resume_from_checkpoint='/content/pretrained.ckpt', profiler=None, benchmark=None, deterministic=None, reload_dataloaders_every_n_epochs=0, auto_lr_find=False, replace_sampler_ddp=True, detect_anomaly=False, auto_scale_batch_size=False, plugins=None, amp_backend='native', amp_level=None, move_metrics_to_cpu=False, multiple_trainloader_mode='max_size_cycle', batch_size=12, validation_split=0.0, num_test_examples=0, max_phoneme_ids=None, hidden_channels=192, inter_channels=192, filter_channels=768, n_layers=6, n_heads=2, seed=1234, num_ckpt=0, save_last=None)
/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/connectors/checkpoint_connector.py:52: LightningDeprecationWarning: Setting Trainer(resume_from_checkpoint=) is deprecated in v1.5 and will be removed in v1.7. Please pass Trainer.fit(ckpt_path=) directly instead.
rank_zero_deprecation(
GPU available: True (cuda), used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
HPU available: False, using: 0 HPUs
DEBUG:piper_train:Checkpoints will be saved every 5 epoch(s)
DEBUG:piper_train:0 Checkpoints will be saved
DEBUG:vits.dataset:Loading dataset: /content/drive/MyDrive/colab/piper/Test/dataset.jsonl
/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py:731: LightningDeprecationWarning: trainer.resume_from_checkpoint is deprecated in v1.5 and will be removed in v2.0. Specify the fit checkpoint path with trainer.fit(ckpt_path=) instead.
ckpt_path = ckpt_path or self.resume_from_checkpoint
Missing logger folder: /content/drive/MyDrive/colab/piper/Test/lightning_logs
Restoring states from the checkpoint path at /content/pretrained.ckpt
DEBUG:fsspec.local:open file: /content/pretrained.ckpt
Traceback (most recent call last):
File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
exec(code, run_globals)
File "/content/piper/src/python/piper_train/main.py", line 173, in
main()
File "/content/piper/src/python/piper_train/main.py", line 150, in main
trainer.fit(model)
File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 696, in fit
self._call_and_handle_interrupt(
File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 650, in _call_and_handle_interrupt
return trainer_fn(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 735, in _fit_impl
results = self._run(model, ckpt_path=self.ckpt_path)
File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 1110, in _run
self._restore_modules_and_callbacks(ckpt_path)
File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 1065, in _restore_modules_and_callbacks
self._checkpoint_connector.restore_model()
File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/connectors/checkpoint_connector.py", line 182, in restore_model
self.trainer.strategy.load_model_state_dict(self._loaded_checkpoint)
File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/strategies/strategy.py", line 343, in load_model_state_dict
self.lightning_module.load_state_dict(checkpoint["state_dict"])
File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1667, in load_state_dict
raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(
RuntimeError: Error(s) in loading state_dict for VitsModel:
Missing key(s) in state_dict: "model_g.dec.ups.3.bias", "model_g.dec.ups.3.weight_g", "model_g.dec.ups.3.weight_v", "model_g.dec.resblocks.0.convs1.0.bias", "model_g.dec.resblocks.0.convs1.0.weight_g", "model_g.dec.resblocks.0.convs1.0.weight_v", "model_g.dec.resblocks.0.convs1.1.bias", "model_g.dec.resblocks.0.convs1.1.weight_g", "model_g.dec.resblocks.0.convs1.1.weight_v", "model_g.dec.resblocks.0.convs1.2.bias", "model_g.dec.resblocks.0.convs1.2.weight_g", "model_g.dec.resblocks.0.convs1.2.weight_v", "model_g.dec.resblocks.0.convs2.0.bias", "model_g.dec.resblocks.0.convs2.0.weight_g", "model_g.dec.resblocks.0.convs2.0.weight_v", "model_g.dec.resblocks.0.convs2.1.bias", "model_g.dec.resblocks.0.convs2.1.weight_g", "model_g.dec.resblocks.0.convs2.1.weight_v", "model_g.dec.resblocks.0.convs2.2.bias", "model_g.dec.resblocks.0.convs2.2.weight_g", "model_g.dec.resblocks.0.convs2.2.weight_v", "model_g.dec.resblocks.1.convs1.0.bias", "model_g.dec.resblocks.1.convs1.0.weight_g", "model_g.dec.resblocks.1.convs1.0.weight_v", "model_g.dec.resblocks.1.convs1.1.bias", "model_g.dec.resblocks.1.convs1.1.weight_g", "model_g.dec.resblocks.1.convs1.1.weight_v", "model_g.dec.resblocks.1.convs1.2.bias", "model_g.dec.resblocks.1.convs1.2.weight_g", "model_g.dec.resblocks.1.convs1.2.weight_v", "model_g.dec.resblocks.1.convs2.0.bias", "model_g.dec.resblocks.1.convs2.0.weight_g", "model_g.dec.resblocks.1.convs2.0.weight_v", "model_g.dec.resblocks.1.convs2.1.bias", "model_g.dec.resblocks.1.convs2.1.weight_g", "model_g.dec.resblocks.1.convs2.1.weight_v", "model_g.dec.resblocks.1.convs2.2.bias", "model_g.dec.resblocks.1.convs2.2.weight_g", "model_g.dec.resblocks.1.convs2.2.weight_v", "model_g.dec.resblocks.2.convs1.0.bias", "model_g.dec.resblocks.2.convs1.0.weight_g", "model_g.dec.resblocks.2.convs1.0.weight_v", "model_g.dec.resblocks.2.convs1.1.bias", "model_g.dec.resblocks.2.convs1.1.weight_g", "model_g.dec.resblocks.2.convs1.1.weight_v", "model_g.dec.resblocks.2.convs1.2.bias", "model_g.dec.resblocks.2.convs1.2.weight_g", "model_g.dec.resblocks.2.convs1.2.weight_v", "model_g.dec.resblocks.2.convs2.0.bias", "model_g.dec.resblocks.2.convs2.0.weight_g", "model_g.dec.resblocks.2.convs2.0.weight_v", "model_g.dec.resblocks.2.convs2.1.bias", "model_g.dec.resblocks.2.convs2.1.weight_g", "model_g.dec.resblocks.2.convs2.1.weight_v", "model_g.dec.resblocks.2.convs2.2.bias", "model_g.dec.resblocks.2.convs2.2.weight_g", "model_g.dec.resblocks.2.convs2.2.weight_v", "model_g.dec.resblocks.3.convs1.0.bias", "model_g.dec.resblocks.3.convs1.0.weight_g", "model_g.dec.resblocks.3.convs1.0.weight_v", "model_g.dec.resblocks.3.convs1.1.bias", "model_g.dec.resblocks.3.convs1.1.weight_g", "model_g.dec.resblocks.3.convs1.1.weight_v", "model_g.dec.resblocks.3.convs1.2.bias", "model_g.dec.resblocks.3.convs1.2.weight_g", "model_g.dec.resblocks.3.convs1.2.weight_v", "model_g.dec.resblocks.3.convs2.0.bias", "model_g.dec.resblocks.3.convs2.0.weight_g", "model_g.dec.resblocks.3.convs2.0.weight_v", "model_g.dec.resblocks.3.convs2.1.bias", "model_g.dec.resblocks.3.convs2.1.weight_g", "model_g.dec.resblocks.3.convs2.1.weight_v", "model_g.dec.resblocks.3.convs2.2.bias", "model_g.dec.resblocks.3.convs2.2.weight_g", "model_g.dec.resblocks.3.convs2.2.weight_v", "model_g.dec.resblocks.4.convs1.0.bias", "model_g.dec.resblocks.4.convs1.0.weight_g", "model_g.dec.resblocks.4.convs1.0.weight_v", "model_g.dec.resblocks.4.convs1.1.bias", "model_g.dec.resblocks.4.convs1.1.weight_g", "model_g.dec.resblocks.4.convs1.1.weight_v", "model_g.dec.resblocks.4.convs1.2.bias", "model_g.dec.resblocks.4.convs1.2.weight_g", "model_g.dec.resblocks.4.convs1.2.weight_v", "model_g.dec.resblocks.4.convs2.0.bias", "model_g.dec.resblocks.4.convs2.0.weight_g", "model_g.dec.resblocks.4.convs2.0.weight_v", "model_g.dec.resblocks.4.convs2.1.bias", "model_g.dec.resblocks.4.convs2.1.weight_g", "model_g.dec.resblocks.4.convs2.1.weight_v", "model_g.dec.resblocks.4.convs2.2.bias", "model_g.dec.resblocks.4.convs2.2.weight_g", "model_g.dec.resblocks.4.convs2.2.weight_v", "model_g.dec.resblocks.5.convs1.0.bias", "model_g.dec.resblocks.5.convs1.0.weight_g", "model_g.dec.resblocks.5.convs1.0.weight_v", "model_g.dec.resblocks.5.convs1.1.bias", "model_g.dec.resblocks.5.convs1.1.weight_g", "model_g.dec.resblocks.5.convs1.1.weight_v", "model_g.dec.resblocks.5.convs1.2.bias", "model_g.dec.resblocks.5.convs1.2.weight_g", "model_g.dec.resblocks.5.convs1.2.weight_v", "model_g.dec.resblocks.5.convs2.0.bias", "model_g.dec.resblocks.5.convs2.0.weight_g", "model_g.dec.resblocks.5.convs2.0.weight_v", "model_g.dec.resblocks.5.convs2.1.bias", "model_g.dec.resblocks.5.convs2.1.weight_g", "model_g.dec.resblocks.5.convs2.1.weight_v", "model_g.dec.resblocks.5.convs2.2.bias", "model_g.dec.resblocks.5.convs2.2.weight_g", "model_g.dec.resblocks.5.convs2.2.weight_v", "model_g.dec.resblocks.6.convs1.0.bias", "model_g.dec.resblocks.6.convs1.0.weight_g", "model_g.dec.resblocks.6.convs1.0.weight_v", "model_g.dec.resblocks.6.convs1.1.bias", "model_g.dec.resblocks.6.convs1.1.weight_g", "model_g.dec.resblocks.6.convs1.1.weight_v", "model_g.dec.resblocks.6.convs1.2.bias", "model_g.dec.resblocks.6.convs1.2.weight_g", "model_g.dec.resblocks.6.convs1.2.weight_v", "model_g.dec.resblocks.6.convs2.0.bias", "model_g.dec.resblocks.6.convs2.0.weight_g", "model_g.dec.resblocks.6.convs2.0.weight_v", "model_g.dec.resblocks.6.convs2.1.bias", "model_g.dec.resblocks.6.convs2.1.weight_g", "model_g.dec.resblocks.6.convs2.1.weight_v", "model_g.dec.resblocks.6.convs2.2.bias", "model_g.dec.resblocks.6.convs2.2.weight_g", "model_g.dec.resblocks.6.convs2.2.weight_v", "model_g.dec.resblocks.7.convs1.0.bias", "model_g.dec.resblocks.7.convs1.0.weight_g", "model_g.dec.resblocks.7.convs1.0.weight_v", "model_g.dec.resblocks.7.convs1.1.bias", "model_g.dec.resblocks.7.convs1.1.weight_g", "model_g.dec.resblocks.7.convs1.1.weight_v", "model_g.dec.resblocks.7.convs1.2.bias", "model_g.dec.resblocks.7.convs1.2.weight_g", "model_g.dec.resblocks.7.convs1.2.weight_v", "model_g.dec.resblocks.7.convs2.0.bias", "model_g.dec.resblocks.7.convs2.0.weight_g", "model_g.dec.resblocks.7.convs2.0.weight_v", "model_g.dec.resblocks.7.convs2.1.bias", "model_g.dec.resblocks.7.convs2.1.weight_g", "model_g.dec.resblocks.7.convs2.1.weight_v", "model_g.dec.resblocks.7.convs2.2.bias", "model_g.dec.resblocks.7.convs2.2.weight_g", "model_g.dec.resblocks.7.convs2.2.weight_v", "model_g.dec.resblocks.8.convs1.0.bias", "model_g.dec.resblocks.8.convs1.0.weight_g", "model_g.dec.resblocks.8.convs1.0.weight_v", "model_g.dec.resblocks.8.convs1.1.bias", "model_g.dec.resblocks.8.convs1.1.weight_g", "model_g.dec.resblocks.8.convs1.1.weight_v", "model_g.dec.resblocks.8.convs1.2.bias", "model_g.dec.resblocks.8.convs1.2.weight_g", "model_g.dec.resblocks.8.convs1.2.weight_v", "model_g.dec.resblocks.8.convs2.0.bias", "model_g.dec.resblocks.8.convs2.0.weight_g", "model_g.dec.resblocks.8.convs2.0.weight_v", "model_g.dec.resblocks.8.convs2.1.bias", "model_g.dec.resblocks.8.convs2.1.weight_g", "model_g.dec.resblocks.8.convs2.1.weight_v", "model_g.dec.resblocks.8.convs2.2.bias", "model_g.dec.resblocks.8.convs2.2.weight_g", "model_g.dec.resblocks.8.convs2.2.weight_v", "model_g.dec.resblocks.9.convs1.0.bias", "model_g.dec.resblocks.9.convs1.0.weight_g", "model_g.dec.resblocks.9.convs1.0.weight_v", "model_g.dec.resblocks.9.convs1.1.bias", "model_g.dec.resblocks.9.convs1.1.weight_g", "model_g.dec.resblocks.9.convs1.1.weight_v", "model_g.dec.resblocks.9.convs1.2.bias", "model_g.dec.resblocks.9.convs1.2.weight_g", "model_g.dec.resblocks.9.convs1.2.weight_v", "model_g.dec.resblocks.9.convs2.0.bias", "model_g.dec.resblocks.9.convs2.0.weight_g", "model_g.dec.resblocks.9.convs2.0.weight_v", "model_g.dec.resblocks.9.convs2.1.bias", "model_g.dec.resblocks.9.convs2.1.weight_g", "model_g.dec.resblocks.9.convs2.1.weight_v", "model_g.dec.resblocks.9.convs2.2.bias", "model_g.dec.resblocks.9.convs2.2.weight_g", "model_g.dec.resblocks.9.convs2.2.weight_v", "model_g.dec.resblocks.10.convs1.0.bias", "model_g.dec.resblocks.10.convs1.0.weight_g", "model_g.dec.resblocks.10.convs1.0.weight_v", "model_g.dec.resblocks.10.convs1.1.bias", "model_g.dec.resblocks.10.convs1.1.weight_g", "model_g.dec.resblocks.10.convs1.1.weight_v", "model_g.dec.resblocks.10.convs1.2.bias", "model_g.dec.resblocks.10.convs1.2.weight_g", "model_g.dec.resblocks.10.convs1.2.weight_v", "model_g.dec.resblocks.10.convs2.0.bias", "model_g.dec.resblocks.10.convs2.0.weight_g", "model_g.dec.resblocks.10.convs2.0.weight_v", "model_g.dec.resblocks.10.convs2.1.bias", "model_g.dec.resblocks.10.convs2.1.weight_g", "model_g.dec.resblocks.10.convs2.1.weight_v", "model_g.dec.resblocks.10.convs2.2.bias", "model_g.dec.resblocks.10.convs2.2.weight_g", "model_g.dec.resblocks.10.convs2.2.weight_v", "model_g.dec.resblocks.11.convs1.0.bias", "model_g.dec.resblocks.11.convs1.0.weight_g", "model_g.dec.resblocks.11.convs1.0.weight_v", "model_g.dec.resblocks.11.convs1.1.bias", "model_g.dec.resblocks.11.convs1.1.weight_g", "model_g.dec.resblocks.11.convs1.1.weight_v", "model_g.dec.resblocks.11.convs1.2.bias", "model_g.dec.resblocks.11.convs1.2.weight_g", "model_g.dec.resblocks.11.convs1.2.weight_v", "model_g.dec.resblocks.11.convs2.0.bias", "model_g.dec.resblocks.11.convs2.0.weight_g", "model_g.dec.resblocks.11.convs2.0.weight_v", "model_g.dec.resblocks.11.convs2.1.bias", "model_g.dec.resblocks.11.convs2.1.weight_g", "model_g.dec.resblocks.11.convs2.1.weight_v", "model_g.dec.resblocks.11.convs2.2.bias", "model_g.dec.resblocks.11.convs2.2.weight_g", "model_g.dec.resblocks.11.convs2.2.weight_v".
Unexpected key(s) in state_dict: "model_g.emb_g.weight", "model_g.dec.cond.weight", "model_g.dec.cond.bias", "model_g.dec.resblocks.0.convs.0.bias", "model_g.dec.resblocks.0.convs.0.weight_g", "model_g.dec.resblocks.0.convs.0.weight_v", "model_g.dec.resblocks.0.convs.1.bias", "model_g.dec.resblocks.0.convs.1.weight_g", "model_g.dec.resblocks.0.convs.1.weight_v", "model_g.dec.resblocks.1.convs.0.bias", "model_g.dec.resblocks.1.convs.0.weight_g", "model_g.dec.resblocks.1.convs.0.weight_v", "model_g.dec.resblocks.1.convs.1.bias", "model_g.dec.resblocks.1.convs.1.weight_g", "model_g.dec.resblocks.1.convs.1.weight_v", "model_g.dec.resblocks.2.convs.0.bias", "model_g.dec.resblocks.2.convs.0.weight_g", "model_g.dec.resblocks.2.convs.0.weight_v", "model_g.dec.resblocks.2.convs.1.bias", "model_g.dec.resblocks.2.convs.1.weight_g", "model_g.dec.resblocks.2.convs.1.weight_v", "model_g.dec.resblocks.3.convs.0.bias", "model_g.dec.resblocks.3.convs.0.weight_g", "model_g.dec.resblocks.3.convs.0.weight_v", "model_g.dec.resblocks.3.convs.1.bias", "model_g.dec.resblocks.3.convs.1.weight_g", "model_g.dec.resblocks.3.convs.1.weight_v", "model_g.dec.resblocks.4.convs.0.bias", "model_g.dec.resblocks.4.convs.0.weight_g", "model_g.dec.resblocks.4.convs.0.weight_v", "model_g.dec.resblocks.4.convs.1.bias", "model_g.dec.resblocks.4.convs.1.weight_g", "model_g.dec.resblocks.4.convs.1.weight_v", "model_g.dec.resblocks.5.convs.0.bias", "model_g.dec.resblocks.5.convs.0.weight_g", "model_g.dec.resblocks.5.convs.0.weight_v", "model_g.dec.resblocks.5.convs.1.bias", "model_g.dec.resblocks.5.convs.1.weight_g", "model_g.dec.resblocks.5.convs.1.weight_v", "model_g.dec.resblocks.6.convs.0.bias", "model_g.dec.resblocks.6.convs.0.weight_g", "model_g.dec.resblocks.6.convs.0.weight_v", "model_g.dec.resblocks.6.convs.1.bias", "model_g.dec.resblocks.6.convs.1.weight_g", "model_g.dec.resblocks.6.convs.1.weight_v", "model_g.dec.resblocks.7.convs.0.bias", "model_g.dec.resblocks.7.convs.0.weight_g", "model_g.dec.resblocks.7.convs.0.weight_v", "model_g.dec.resblocks.7.convs.1.bias", "model_g.dec.resblocks.7.convs.1.weight_g", "model_g.dec.resblocks.7.convs.1.weight_v", "model_g.dec.resblocks.8.convs.0.bias", "model_g.dec.resblocks.8.convs.0.weight_g", "model_g.dec.resblocks.8.convs.0.weight_v", "model_g.dec.resblocks.8.convs.1.bias", "model_g.dec.resblocks.8.convs.1.weight_g", "model_g.dec.resblocks.8.convs.1.weight_v", "model_g.enc_q.enc.cond_layer.bias", "model_g.enc_q.enc.cond_layer.weight_g", "model_g.enc_q.enc.cond_layer.weight_v", "model_g.flow.flows.0.enc.cond_layer.bias", "model_g.flow.flows.0.enc.cond_layer.weight_g", "model_g.flow.flows.0.enc.cond_layer.weight_v", "model_g.flow.flows.2.enc.cond_layer.bias", "model_g.flow.flows.2.enc.cond_layer.weight_g", "model_g.flow.flows.2.enc.cond_layer.weight_v", "model_g.flow.flows.4.enc.cond_layer.bias", "model_g.flow.flows.4.enc.cond_layer.weight_g", "model_g.flow.flows.4.enc.cond_layer.weight_v", "model_g.flow.flows.6.enc.cond_layer.bias", "model_g.flow.flows.6.enc.cond_layer.weight_g", "model_g.flow.flows.6.enc.cond_layer.weight_v", "model_g.dp.cond.weight", "model_g.dp.cond.bias".
size mismatch for model_g.dec.conv_pre.weight: copying a param with shape torch.Size([256, 192, 7]) from checkpoint, the shape in current model is torch.Size([512, 192, 7]).
size mismatch for model_g.dec.conv_pre.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for model_g.dec.ups.0.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for model_g.dec.ups.0.weight_g: copying a param with shape torch.Size([256, 1, 1]) from checkpoint, the shape in current model is torch.Size([512, 1, 1]).
size mismatch for model_g.dec.ups.0.weight_v: copying a param with shape torch.Size([256, 128, 16]) from checkpoint, the shape in current model is torch.Size([512, 256, 16]).
size mismatch for model_g.dec.ups.1.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for model_g.dec.ups.1.weight_g: copying a param with shape torch.Size([128, 1, 1]) from checkpoint, the shape in current model is torch.Size([256, 1, 1]).
size mismatch for model_g.dec.ups.1.weight_v: copying a param with shape torch.Size([128, 64, 16]) from checkpoint, the shape in current model is torch.Size([256, 128, 16]).
size mismatch for model_g.dec.ups.2.bias: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for model_g.dec.ups.2.weight_g: copying a param with shape torch.Size([64, 1, 1]) from checkpoint, the shape in current model is torch.Size([128, 1, 1]).
size mismatch for model_g.dec.ups.2.weight_v: copying a param with shape torch.Size([64, 32, 8]) from checkpoint, the shape in current model is torch.Size([128, 64, 4]).

DEBUG:piper_train:Namespace(dataset_dir='/content/drive/MyDrive/colab/piper/Test', checkpoint_epochs=5, quality='high', resume_from_single_speaker_checkpoint=None, logger=True, enable_checkpointing=True, default_root_dir=None, gradient_clip_val=None, gradient_clip_algorithm=None, num_nodes=1, num_processes=None, devices='1', gpus=None, auto_select_gpus=False, tpu_cores=None, ipus=None, enable_progress_bar=True, overfit_batches=0.0, track_grad_norm=-1, check_val_every_n_epoch=1, fast_dev_run=False, accumulate_grad_batches=None, max_epochs=10000, min_epochs=None, max_steps=-1, min_steps=None, max_time=None, limit_train_batches=None, limit_val_batches=None, limit_test_batches=None, limit_predict_batches=None, val_check_interval=None, log_every_n_steps=1000, accelerator='gpu', strategy=None, sync_batchnorm=False, precision=32, enable_model_summary=True, weights_save_path=None, num_sanity_val_steps=2, resume_from_checkpoint='/content/pretrained.ckpt', profiler=None, benchmark=None, deterministic=None, reload_dataloaders_every_n_epochs=0, auto_lr_find=False, replace_sampler_ddp=True, detect_anomaly=False, auto_scale_batch_size=False, plugins=None, amp_backend='native', amp_level=None, move_metrics_to_cpu=False, multiple_trainloader_mode='max_size_cycle', batch_size=12, validation_split=0.0, num_test_examples=0, max_phoneme_ids=None, hidden_channels=192, inter_channels=192, filter_channels=768, n_layers=6, n_heads=2, seed=1234, num_ckpt=0, save_last=None) /usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/connectors/checkpoint_connector.py:52: LightningDeprecationWarning: Setting Trainer(resume_from_checkpoint=) is deprecated in v1.5 and will be removed in v1.7. Please pass Trainer.fit(ckpt_path=) directly instead. rank_zero_deprecation( GPU available: True (cuda), used: True TPU available: False, using: 0 TPU cores IPU available: False, using: 0 IPUs HPU available: False, using: 0 HPUs DEBUG:piper_train:Checkpoints will be saved every 5 epoch(s) DEBUG:piper_train:0 Checkpoints will be saved DEBUG:vits.dataset:Loading dataset: /content/drive/MyDrive/colab/piper/Test/dataset.jsonl /usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py:731: LightningDeprecationWarning: trainer.resume_from_checkpoint is deprecated in v1.5 and will be removed in v2.0. Specify the fit checkpoint path with trainer.fit(ckpt_path=) instead. ckpt_path = ckpt_path or self.resume_from_checkpoint Missing logger folder: /content/drive/MyDrive/colab/piper/Test/lightning_logs Restoring states from the checkpoint path at /content/pretrained.ckpt DEBUG:fsspec.local:open file: /content/pretrained.ckpt Traceback (most recent call last): File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/lib/python3.10/runpy.py", line 86, in _run_code exec(code, run_globals) File "/content/piper/src/python/piper_train/main.py", line 173, in main() File "/content/piper/src/python/piper_train/main.py", line 150, in main trainer.fit(model) File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 696, in fit self._call_and_handle_interrupt( File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 650, in _call_and_handle_interrupt return trainer_fn(*args, **kwargs) File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 735, in _fit_impl results = self._run(model, ckpt_path=self.ckpt_path) File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 1110, in _run self._restore_modules_and_callbacks(ckpt_path) File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/trainer.py", line 1065, in _restore_modules_and_callbacks self._checkpoint_connector.restore_model() File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/trainer/connectors/checkpoint_connector.py", line 182, in restore_model self.trainer.strategy.load_model_state_dict(self._loaded_checkpoint) File "/usr/local/lib/python3.10/dist-packages/pytorch_lightning/strategies/strategy.py", line 343, in load_model_state_dict self.lightning_module.load_state_dict(checkpoint["state_dict"]) File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1667, in load_state_dict raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format( RuntimeError: Error(s) in loading state_dict for VitsModel: Missing key(s) in state_dict: "model_g.dec.ups.3.bias", "model_g.dec.ups.3.weight_g", "model_g.dec.ups.3.weight_v", "model_g.dec.resblocks.0.convs1.0.bias", "model_g.dec.resblocks.0.convs1.0.weight_g", "model_g.dec.resblocks.0.convs1.0.weight_v", "model_g.dec.resblocks.0.convs1.1.bias", "model_g.dec.resblocks.0.convs1.1.weight_g", "model_g.dec.resblocks.0.convs1.1.weight_v", "model_g.dec.resblocks.0.convs1.2.bias", "model_g.dec.resblocks.0.convs1.2.weight_g", "model_g.dec.resblocks.0.convs1.2.weight_v", "model_g.dec.resblocks.0.convs2.0.bias", "model_g.dec.resblocks.0.convs2.0.weight_g", "model_g.dec.resblocks.0.convs2.0.weight_v", "model_g.dec.resblocks.0.convs2.1.bias", "model_g.dec.resblocks.0.convs2.1.weight_g", "model_g.dec.resblocks.0.convs2.1.weight_v", "model_g.dec.resblocks.0.convs2.2.bias", "model_g.dec.resblocks.0.convs2.2.weight_g", "model_g.dec.resblocks.0.convs2.2.weight_v", "model_g.dec.resblocks.1.convs1.0.bias", "model_g.dec.resblocks.1.convs1.0.weight_g", "model_g.dec.resblocks.1.convs1.0.weight_v", "model_g.dec.resblocks.1.convs1.1.bias", "model_g.dec.resblocks.1.convs1.1.weight_g", "model_g.dec.resblocks.1.convs1.1.weight_v", "model_g.dec.resblocks.1.convs1.2.bias", "model_g.dec.resblocks.1.convs1.2.weight_g", "model_g.dec.resblocks.1.convs1.2.weight_v", "model_g.dec.resblocks.1.convs2.0.bias", "model_g.dec.resblocks.1.convs2.0.weight_g", "model_g.dec.resblocks.1.convs2.0.weight_v", "model_g.dec.resblocks.1.convs2.1.bias", "model_g.dec.resblocks.1.convs2.1.weight_g", "model_g.dec.resblocks.1.convs2.1.weight_v", "model_g.dec.resblocks.1.convs2.2.bias", "model_g.dec.resblocks.1.convs2.2.weight_g", "model_g.dec.resblocks.1.convs2.2.weight_v", "model_g.dec.resblocks.2.convs1.0.bias", "model_g.dec.resblocks.2.convs1.0.weight_g", "model_g.dec.resblocks.2.convs1.0.weight_v", "model_g.dec.resblocks.2.convs1.1.bias", "model_g.dec.resblocks.2.convs1.1.weight_g", "model_g.dec.resblocks.2.convs1.1.weight_v", "model_g.dec.resblocks.2.convs1.2.bias", "model_g.dec.resblocks.2.convs1.2.weight_g", "model_g.dec.resblocks.2.convs1.2.weight_v", "model_g.dec.resblocks.2.convs2.0.bias", "model_g.dec.resblocks.2.convs2.0.weight_g", "model_g.dec.resblocks.2.convs2.0.weight_v", "model_g.dec.resblocks.2.convs2.1.bias", "model_g.dec.resblocks.2.convs2.1.weight_g", "model_g.dec.resblocks.2.convs2.1.weight_v", "model_g.dec.resblocks.2.convs2.2.bias", "model_g.dec.resblocks.2.convs2.2.weight_g", "model_g.dec.resblocks.2.convs2.2.weight_v", "model_g.dec.resblocks.3.convs1.0.bias", "model_g.dec.resblocks.3.convs1.0.weight_g", "model_g.dec.resblocks.3.convs1.0.weight_v", "model_g.dec.resblocks.3.convs1.1.bias", "model_g.dec.resblocks.3.convs1.1.weight_g", "model_g.dec.resblocks.3.convs1.1.weight_v", "model_g.dec.resblocks.3.convs1.2.bias", "model_g.dec.resblocks.3.convs1.2.weight_g", "model_g.dec.resblocks.3.convs1.2.weight_v", "model_g.dec.resblocks.3.convs2.0.bias", "model_g.dec.resblocks.3.convs2.0.weight_g", "model_g.dec.resblocks.3.convs2.0.weight_v", "model_g.dec.resblocks.3.convs2.1.bias", "model_g.dec.resblocks.3.convs2.1.weight_g", "model_g.dec.resblocks.3.convs2.1.weight_v", "model_g.dec.resblocks.3.convs2.2.bias", "model_g.dec.resblocks.3.convs2.2.weight_g", "model_g.dec.resblocks.3.convs2.2.weight_v", "model_g.dec.resblocks.4.convs1.0.bias", "model_g.dec.resblocks.4.convs1.0.weight_g", "model_g.dec.resblocks.4.convs1.0.weight_v", "model_g.dec.resblocks.4.convs1.1.bias", "model_g.dec.resblocks.4.convs1.1.weight_g", "model_g.dec.resblocks.4.convs1.1.weight_v", "model_g.dec.resblocks.4.convs1.2.bias", "model_g.dec.resblocks.4.convs1.2.weight_g", "model_g.dec.resblocks.4.convs1.2.weight_v", "model_g.dec.resblocks.4.convs2.0.bias", "model_g.dec.resblocks.4.convs2.0.weight_g", "model_g.dec.resblocks.4.convs2.0.weight_v", "model_g.dec.resblocks.4.convs2.1.bias", "model_g.dec.resblocks.4.convs2.1.weight_g", "model_g.dec.resblocks.4.convs2.1.weight_v", "model_g.dec.resblocks.4.convs2.2.bias", "model_g.dec.resblocks.4.convs2.2.weight_g", "model_g.dec.resblocks.4.convs2.2.weight_v", "model_g.dec.resblocks.5.convs1.0.bias", "model_g.dec.resblocks.5.convs1.0.weight_g", "model_g.dec.resblocks.5.convs1.0.weight_v", "model_g.dec.resblocks.5.convs1.1.bias", "model_g.dec.resblocks.5.convs1.1.weight_g", "model_g.dec.resblocks.5.convs1.1.weight_v", "model_g.dec.resblocks.5.convs1.2.bias", "model_g.dec.resblocks.5.convs1.2.weight_g", "model_g.dec.resblocks.5.convs1.2.weight_v", "model_g.dec.resblocks.5.convs2.0.bias", "model_g.dec.resblocks.5.convs2.0.weight_g", "model_g.dec.resblocks.5.convs2.0.weight_v", "model_g.dec.resblocks.5.convs2.1.bias", "model_g.dec.resblocks.5.convs2.1.weight_g", "model_g.dec.resblocks.5.convs2.1.weight_v", "model_g.dec.resblocks.5.convs2.2.bias", "model_g.dec.resblocks.5.convs2.2.weight_g", "model_g.dec.resblocks.5.convs2.2.weight_v", "model_g.dec.resblocks.6.convs1.0.bias", "model_g.dec.resblocks.6.convs1.0.weight_g", "model_g.dec.resblocks.6.convs1.0.weight_v", "model_g.dec.resblocks.6.convs1.1.bias", "model_g.dec.resblocks.6.convs1.1.weight_g", "model_g.dec.resblocks.6.convs1.1.weight_v", "model_g.dec.resblocks.6.convs1.2.bias", "model_g.dec.resblocks.6.convs1.2.weight_g", "model_g.dec.resblocks.6.convs1.2.weight_v", "model_g.dec.resblocks.6.convs2.0.bias", "model_g.dec.resblocks.6.convs2.0.weight_g", "model_g.dec.resblocks.6.convs2.0.weight_v", "model_g.dec.resblocks.6.convs2.1.bias", "model_g.dec.resblocks.6.convs2.1.weight_g", "model_g.dec.resblocks.6.convs2.1.weight_v", "model_g.dec.resblocks.6.convs2.2.bias", "model_g.dec.resblocks.6.convs2.2.weight_g", "model_g.dec.resblocks.6.convs2.2.weight_v", "model_g.dec.resblocks.7.convs1.0.bias", "model_g.dec.resblocks.7.convs1.0.weight_g", "model_g.dec.resblocks.7.convs1.0.weight_v", "model_g.dec.resblocks.7.convs1.1.bias", "model_g.dec.resblocks.7.convs1.1.weight_g", "model_g.dec.resblocks.7.convs1.1.weight_v", "model_g.dec.resblocks.7.convs1.2.bias", "model_g.dec.resblocks.7.convs1.2.weight_g", "model_g.dec.resblocks.7.convs1.2.weight_v", "model_g.dec.resblocks.7.convs2.0.bias", "model_g.dec.resblocks.7.convs2.0.weight_g", "model_g.dec.resblocks.7.convs2.0.weight_v", "model_g.dec.resblocks.7.convs2.1.bias", "model_g.dec.resblocks.7.convs2.1.weight_g", "model_g.dec.resblocks.7.convs2.1.weight_v", "model_g.dec.resblocks.7.convs2.2.bias", "model_g.dec.resblocks.7.convs2.2.weight_g", "model_g.dec.resblocks.7.convs2.2.weight_v", "model_g.dec.resblocks.8.convs1.0.bias", "model_g.dec.resblocks.8.convs1.0.weight_g", "model_g.dec.resblocks.8.convs1.0.weight_v", "model_g.dec.resblocks.8.convs1.1.bias", "model_g.dec.resblocks.8.convs1.1.weight_g", "model_g.dec.resblocks.8.convs1.1.weight_v", "model_g.dec.resblocks.8.convs1.2.bias", "model_g.dec.resblocks.8.convs1.2.weight_g", "model_g.dec.resblocks.8.convs1.2.weight_v", "model_g.dec.resblocks.8.convs2.0.bias", "model_g.dec.resblocks.8.convs2.0.weight_g", "model_g.dec.resblocks.8.convs2.0.weight_v", "model_g.dec.resblocks.8.convs2.1.bias", "model_g.dec.resblocks.8.convs2.1.weight_g", "model_g.dec.resblocks.8.convs2.1.weight_v", "model_g.dec.resblocks.8.convs2.2.bias", "model_g.dec.resblocks.8.convs2.2.weight_g", "model_g.dec.resblocks.8.convs2.2.weight_v", "model_g.dec.resblocks.9.convs1.0.bias", "model_g.dec.resblocks.9.convs1.0.weight_g", "model_g.dec.resblocks.9.convs1.0.weight_v", "model_g.dec.resblocks.9.convs1.1.bias", "model_g.dec.resblocks.9.convs1.1.weight_g", "model_g.dec.resblocks.9.convs1.1.weight_v", "model_g.dec.resblocks.9.convs1.2.bias", "model_g.dec.resblocks.9.convs1.2.weight_g", "model_g.dec.resblocks.9.convs1.2.weight_v", "model_g.dec.resblocks.9.convs2.0.bias", "model_g.dec.resblocks.9.convs2.0.weight_g", "model_g.dec.resblocks.9.convs2.0.weight_v", "model_g.dec.resblocks.9.convs2.1.bias", "model_g.dec.resblocks.9.convs2.1.weight_g", "model_g.dec.resblocks.9.convs2.1.weight_v", "model_g.dec.resblocks.9.convs2.2.bias", "model_g.dec.resblocks.9.convs2.2.weight_g", "model_g.dec.resblocks.9.convs2.2.weight_v", "model_g.dec.resblocks.10.convs1.0.bias", "model_g.dec.resblocks.10.convs1.0.weight_g", "model_g.dec.resblocks.10.convs1.0.weight_v", "model_g.dec.resblocks.10.convs1.1.bias", "model_g.dec.resblocks.10.convs1.1.weight_g", "model_g.dec.resblocks.10.convs1.1.weight_v", "model_g.dec.resblocks.10.convs1.2.bias", "model_g.dec.resblocks.10.convs1.2.weight_g", "model_g.dec.resblocks.10.convs1.2.weight_v", "model_g.dec.resblocks.10.convs2.0.bias", "model_g.dec.resblocks.10.convs2.0.weight_g", "model_g.dec.resblocks.10.convs2.0.weight_v", "model_g.dec.resblocks.10.convs2.1.bias", "model_g.dec.resblocks.10.convs2.1.weight_g", "model_g.dec.resblocks.10.convs2.1.weight_v", "model_g.dec.resblocks.10.convs2.2.bias", "model_g.dec.resblocks.10.convs2.2.weight_g", "model_g.dec.resblocks.10.convs2.2.weight_v", "model_g.dec.resblocks.11.convs1.0.bias", "model_g.dec.resblocks.11.convs1.0.weight_g", "model_g.dec.resblocks.11.convs1.0.weight_v", "model_g.dec.resblocks.11.convs1.1.bias", "model_g.dec.resblocks.11.convs1.1.weight_g", "model_g.dec.resblocks.11.convs1.1.weight_v", "model_g.dec.resblocks.11.convs1.2.bias", "model_g.dec.resblocks.11.convs1.2.weight_g", "model_g.dec.resblocks.11.convs1.2.weight_v", "model_g.dec.resblocks.11.convs2.0.bias", "model_g.dec.resblocks.11.convs2.0.weight_g", "model_g.dec.resblocks.11.convs2.0.weight_v", "model_g.dec.resblocks.11.convs2.1.bias", "model_g.dec.resblocks.11.convs2.1.weight_g", "model_g.dec.resblocks.11.convs2.1.weight_v", "model_g.dec.resblocks.11.convs2.2.bias", "model_g.dec.resblocks.11.convs2.2.weight_g", "model_g.dec.resblocks.11.convs2.2.weight_v". Unexpected key(s) in state_dict: "model_g.emb_g.weight", "model_g.dec.cond.weight", "model_g.dec.cond.bias", "model_g.dec.resblocks.0.convs.0.bias", "model_g.dec.resblocks.0.convs.0.weight_g", "model_g.dec.resblocks.0.convs.0.weight_v", "model_g.dec.resblocks.0.convs.1.bias", "model_g.dec.resblocks.0.convs.1.weight_g", "model_g.dec.resblocks.0.convs.1.weight_v", "model_g.dec.resblocks.1.convs.0.bias", "model_g.dec.resblocks.1.convs.0.weight_g", "model_g.dec.resblocks.1.convs.0.weight_v", "model_g.dec.resblocks.1.convs.1.bias", "model_g.dec.resblocks.1.convs.1.weight_g", "model_g.dec.resblocks.1.convs.1.weight_v", "model_g.dec.resblocks.2.convs.0.bias", "model_g.dec.resblocks.2.convs.0.weight_g", "model_g.dec.resblocks.2.convs.0.weight_v", "model_g.dec.resblocks.2.convs.1.bias", "model_g.dec.resblocks.2.convs.1.weight_g", "model_g.dec.resblocks.2.convs.1.weight_v", "model_g.dec.resblocks.3.convs.0.bias", "model_g.dec.resblocks.3.convs.0.weight_g", "model_g.dec.resblocks.3.convs.0.weight_v", "model_g.dec.resblocks.3.convs.1.bias", "model_g.dec.resblocks.3.convs.1.weight_g", "model_g.dec.resblocks.3.convs.1.weight_v", "model_g.dec.resblocks.4.convs.0.bias", "model_g.dec.resblocks.4.convs.0.weight_g", "model_g.dec.resblocks.4.convs.0.weight_v", "model_g.dec.resblocks.4.convs.1.bias", "model_g.dec.resblocks.4.convs.1.weight_g", "model_g.dec.resblocks.4.convs.1.weight_v", "model_g.dec.resblocks.5.convs.0.bias", "model_g.dec.resblocks.5.convs.0.weight_g", "model_g.dec.resblocks.5.convs.0.weight_v", "model_g.dec.resblocks.5.convs.1.bias", "model_g.dec.resblocks.5.convs.1.weight_g", "model_g.dec.resblocks.5.convs.1.weight_v", "model_g.dec.resblocks.6.convs.0.bias", "model_g.dec.resblocks.6.convs.0.weight_g", "model_g.dec.resblocks.6.convs.0.weight_v", "model_g.dec.resblocks.6.convs.1.bias", "model_g.dec.resblocks.6.convs.1.weight_g", "model_g.dec.resblocks.6.convs.1.weight_v", "model_g.dec.resblocks.7.convs.0.bias", "model_g.dec.resblocks.7.convs.0.weight_g", "model_g.dec.resblocks.7.convs.0.weight_v", "model_g.dec.resblocks.7.convs.1.bias", "model_g.dec.resblocks.7.convs.1.weight_g", "model_g.dec.resblocks.7.convs.1.weight_v", "model_g.dec.resblocks.8.convs.0.bias", "model_g.dec.resblocks.8.convs.0.weight_g", "model_g.dec.resblocks.8.convs.0.weight_v", "model_g.dec.resblocks.8.convs.1.bias", "model_g.dec.resblocks.8.convs.1.weight_g", "model_g.dec.resblocks.8.convs.1.weight_v", "model_g.enc_q.enc.cond_layer.bias", "model_g.enc_q.enc.cond_layer.weight_g", "model_g.enc_q.enc.cond_layer.weight_v", "model_g.flow.flows.0.enc.cond_layer.bias", "model_g.flow.flows.0.enc.cond_layer.weight_g", "model_g.flow.flows.0.enc.cond_layer.weight_v", "model_g.flow.flows.2.enc.cond_layer.bias", "model_g.flow.flows.2.enc.cond_layer.weight_g", "model_g.flow.flows.2.enc.cond_layer.weight_v", "model_g.flow.flows.4.enc.cond_layer.bias", "model_g.flow.flows.4.enc.cond_layer.weight_g", "model_g.flow.flows.4.enc.cond_layer.weight_v", "model_g.flow.flows.6.enc.cond_layer.bias", "model_g.flow.flows.6.enc.cond_layer.weight_g", "model_g.flow.flows.6.enc.cond_layer.weight_v", "model_g.dp.cond.weight", "model_g.dp.cond.bias". size mismatch for model_g.dec.conv_pre.weight: copying a param with shape torch.Size([256, 192, 7]) from checkpoint, the shape in current model is torch.Size([512, 192, 7]). size mismatch for model_g.dec.conv_pre.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]). size mismatch for model_g.dec.ups.0.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]). size mismatch for model_g.dec.ups.0.weight_g: copying a param with shape torch.Size([256, 1, 1]) from checkpoint, the shape in current model is torch.Size([512, 1, 1]). size mismatch for model_g.dec.ups.0.weight_v: copying a param with shape torch.Size([256, 128, 16]) from checkpoint, the shape in current model is torch.Size([512, 256, 16]). size mismatch for model_g.dec.ups.1.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]). size mismatch for model_g.dec.ups.1.weight_g: copying a param with shape torch.Size([128, 1, 1]) from checkpoint, the shape in current model is torch.Size([256, 1, 1]). size mismatch for model_g.dec.ups.1.weight_v: copying a param with shape torch.Size([128, 64, 16]) from checkpoint, the shape in current model is torch.Size([256, 128, 16]). size mismatch for model_g.dec.ups.2.bias: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([64]). size mismatch for model_g.dec.ups.2.weight_g: copying a param with shape torch.Size([64, 1, 1]) from checkpoint, the shape in current model is torch.Size([128, 1, 1]). size mismatch for model_g.dec.ups.2.weight_v: copying a param with shape torch.Size([64, 32, 8]) from checkpoint, the shape in current model is torch.Size([128, 64, 4]).

Hi @rafamape10100,
Are you training a single or multispeaker model?
For the first, you'll need to download a singlespeaker checkpoint in step 4.
Cheers.


Allow beacon to tell validator not to propose because not connected

When the beacon chain is syncing or isn't connected to the network, it should tell the validator module not to propose any blocks and not accept any blocks until the chain is fully synced and the client is connected.

Stale


Feature Request: Add BGP Peer Groups

Add a to the data model the ability to track BGP Peer Groups.
BTW really slick setup!  Thanks for sharing!

Do you want to track BGP Peer Groups as a particular model or as a new field in the BGP Session model?

I thinks it's just the ability to define a peer-group and associate that to a BGP session.

It'll also make sense to add the ASN, and import/export policies fields to a peer group since most devices support this feature.


[DO NOT MERGE] Remove reverse proxy for drug-analysis-prints

This relates to https://govuk.zendesk.com/agent/tickets/1453127
We're removing the reverse proxy configuration for /drug-analysis-prints/ as MHRA have a new site which they want to manage mappings for.
The PDFs under /home/groups/public/documents/sentineldocuments/ appear to all 404 now so we're removing this now.  I've requested that MHRA add mappings for these as there are 1436 of these without mappings.

We can't merge these yet as they've got to fix mappings at https://transition.publishing.service.gov.uk/sites/mhra/mappings?path_contains=%2Fhome%2Fgroups%2Fpublic%2Fdocuments%2Fsentineldocuments%2F&utf8=✓ first

They've put mappings in, so this is good to go!


shapes are not in standard layout

I'm running maskrcnn  onnx model from  link
and get the error below
terminate called after throwing an instance of 'migraphx::version_1::exception'
  what():  /code/AMDMIGraphX/src/include/migraphx/check_shapes.hpp:211: standard: scatter_none: Shapes are not in standard layout
[1]    37853 abort (core dumped)  migraphx-driver perf --onnx MaskRCNN-12.onnx

using MIGraphX Version: 2.3 compiled from latest develop branch and rocm=5.2.1 on mi210

This model requires dynamic shape support. The page supplied says:

This model can take images of different sizes as input. However, to achieve best performance, it is recommended to resize the image such that both height and width are within the range of [800, 1333], and then pad the image with zeros such that both height and width are divisible by 32.

The mentioned error is from the scatter op requiring standard shapes and the model presumably passing a broadcasted shape.

need to check/update scatter op so that it works with nonstandard shapes

What happens when the image shape is fixed with something like driver run MaskRCNN-12.onnx --input-dim @image 3 800 800 and scatter is set to allow nonstandard shapes

compute_shape error with certain image sizes
does run with the image size of [3, 800, 800] and some others
verify fails with image size [3, 800, 800]

Hi, I delete the code to check shapes and it works, but fp16 still get error
terminate called after throwing an instance of 'migraphx::version_1::exception'
  what():  /code/AMDMIGraphX/src/include/migraphx/op/get_tuple_elem.hpp:56: compute_shape: GET_TUPLE_ELEM: index 0 is out of range 0
[1]    185791 abort (core dumped)  migraphx-driver perf --onnx MaskRCNN-12.onnx --input-dim @image 3 800 800 --fp16

The verify command that checks between the reference and GPU versions doesn't pass, so there's probably some bugs. Will have to investigate.


New logo!

This will give the Containers top page a uniform taste.
https://github.com/containers
Made by @mairin and Red Hat designer team. Thanks!

https://github.com/containers/common/pull/1409

Love it!

Codecov Report

Merging #1782 (e54f2df) into main (adc633a) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1782      +/-   ##
==========================================
- Coverage   68.65%   68.64%   -0.01%
==========================================
  Files         121      121
  Lines       13324    13324
==========================================
- Hits         9147     9146       -1
- Misses       4177     4178       +1

Designed by Jess Chitas :)


Reservation docs

The current notebook is still available in the new devsite, though hidden from the nav. We could hide it better.
With the new UI we should rethink how we want to document reservations.

Should be a simple fix, here's the doc in question:
https://quantumai.google/cirq/tutorials/google/reservations


[WIP]: Issue 139/add rq graphql

So the function works but it runs after the page rerenders...

Here goes nothing.


fix issues with stale elements

Looking at how these tests were stubbed, I noticed some issues.

Result of element going stale between assert exists and action should be the same as other times an element goes stale - (UnknownObjectException not StaleElementReferenceError)

Removing an element from the DOM isn't accurately modeling an element going stale, so I don't even know what that is attempting to test.

Due to performance issues we no longer check for staleness from the top. We check the bottom element and re-look everything up if that one is stale.

Whoops. I put that in there to make sure it worked for both, it wasn't supposed to stay in. I'll fix it. Thank you.

Coverage decreased (-0.01%) to 94.899% when pulling f606d57f78012f94ea24bba13037b93e11a7e101 on titusfortner:stale_fixes into 7cbf1d76e7b4e10e6afbde53491e4d64327c91ad on watir:master.

Coverage decreased (-0.02%) to 94.888% when pulling cad052d943a085a3bea0a6d7287d25dc70602d26 on titusfortner:stale_fixes into 7cbf1d76e7b4e10e6afbde53491e4d64327c91ad on watir:master.

Coverage decreased (-0.01%) to 94.903% when pulling 7e12186dd407a9c4f28fe0f2d919c0ea5188f10c on titusfortner:stale_fixes into 6f55c8b2f463d5151b4cbacadd021685ed41ec70 on watir:master.


Release serde_with_macros 1.2.0-alpha.2

Release a new version with a serde_as macro which is actually usable.

Update Changelog

bors r+


[!!!!IMPORTANT!!!!] [BUGFIX] Accidentally put the wrong variable here

didn't break the panel and you could still log in which is why i didn't notice it while testing, but not if you clear the webpanel_users table it stops allowing people to log in

This currently prevents people from logging in if the webpanel_users table is cleared, which is the case in all live instances of the panel at the moment @ExpDev07

If that's the issue, could we revert back to Laravel's auth system? I don't think the clearing of that table is an issue with the web panel. It should create an user for them if it doesn't exist.

Its not an issue anymore, it was just cause i was accessing a variable that wasn't filled when you would clear the webpanel_users table but now i fixed it to use the correct variable which is aways filled so it will not cause an issue.


Configure keyup enter to button

Description
Is there a way to configure @keyup.enter to a Button component?
Why Oruga need this feature
Sometimes in some forms it is useful to be able to do this.
Please add "question" tag for this Issue. Thank you!

<o-button @keyup.enter>Btn</o-button>, like native button

Can you reproduce on codepen or similar?


Quick question

How i can create/acces the warehouses ?

You need online-interiors/Bob74IPL (forgot which one), and it's the warehouse in La Mesa.


Ionic 2, rc1, npm run build, errors

Hi
When I npm run build  with RC1 and latest version of ionic-app-scripts (0.0.36) I'm getting this error:
[11:40:44]  Error: Cannot determine the module for component BrowserPopover!
[11:40:44]  ngc failed
[11:40:44]  ionic-app-script task: "build"
[11:40:44]  Error: Error

Previously OK with RC0. FYI BrowserPopover is an additional component which is included in browser.ts and references html template in its own file (components/browser-popover).
Any thoughts?

The new  build process highlighted the fact that I had duplicate component ts files. One in the component file and one in parent page. Closed.


Stopped working because of magister update :(

Last login: Wed Jul 12 08:38:46 on console
iMac-van-K:~ ksuler$ /Users/ksuler/Desktop/Calendar.command ; exit;
[] 14:46:39 Magister Calendar v1.8.3 started.
[] System Time: 14:46:39, date: Thu, 13 Jul 2017 12:46:39 GMT
[] 14:46:39 Debugging has been disabled.
[] 14:46:39 Using default period to fetch appointments for.
[] 14:46:39 Determined period is:
From Thu Jul 13 2017 14:46:39 GMT+0200 (CEST)
To Fri Jul 21 2017 14:46:39 GMT+0200 (CEST).
[] 14:46:39 Google OAuth2 token has expired. Requesting a new one.
/Users/ksuler/Desktop/magister-calendar-master/magister-calendar.js:219
tools.log("critical", "Problem requesting new OAuth2 token: "+result.error.errors[0].message, result.error);
^
TypeError: Cannot read property '0' of undefined
at Request._callback (/Users/ksuler/Desktop/magister-calendar-master/magister-calendar.js:219:88)
at Request.self.callback (/Users/ksuler/Desktop/magister-calendar-master/node_modules/request/request.js:198:22)
at emitTwo (events.js:125:13)
at Request.emit (events.js:213:7)
at Request. (/Users/ksuler/Desktop/magister-calendar-master/node_modules/request/request.js:1082:10)
at emitOne (events.js:120:20)
at Request.emit (events.js:210:7)
at IncomingMessage. (/Users/ksuler/Desktop/magister-calendar-master/node_modules/request/request.js:1009:12)
at emitNone (events.js:110:20)
at IncomingMessage.emit (events.js:207:7)
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
Deleting expired sessions...none found.
[Proces voltooid]

Thanks for reporting your issue. The problem seems to be unrelated to MagisterJS. As the log says, an error occurred while trying to obtain a new OAuth2 token from the Google Calendar API.
It seems that the Google Calendar API returned an unexpected error object. Could you please share the full response?

What do I need to send, this is all terminal said

Please enable debugging on line 23 (var DEBUG = true) in the magister-calendar.js file, and then share the Google API response files saved to disk in the cache folder.

It says the debug log gets saved to disk, but I can't find it

Last login: Sat Jul 15 13:57:30 on ttys000
iMac-van-K:~ ksuler$ /Users/ksuler/Desktop/Calendar.command ; exit;
[] 13:58:10 Magister Calendar v1.8.3 started.
[] System Time: 13:58:10, date: Sat, 15 Jul 2017 11:58:10 GMT
[] 13:58:10 Debugging has been enabled. Extra information will be printed, and logs/dumps saved to disk.
[] 13:58:10 Using default period to fetch appointments for.
[] 13:58:10 Determined period is:
From Mon Jul 17 2017 13:58:10 GMT+0200 (CEST)
To Sat Jul 29 2017 13:58:10 GMT+0200 (CEST).
[] 13:58:10 Google OAuth2 token has expired. Requesting a new one.
/Users/ksuler/Desktop/magister-calendar-master/magister-calendar.js:219
tools.log("critical", "Problem requesting new OAuth2 token: "+result.error.errors[0].message, result.error);
^
TypeError: Cannot read property '0' of undefined
at Request._callback (/Users/ksuler/Desktop/magister-calendar-master/magister-calendar.js:219:88)
at Request.self.callback (/Users/ksuler/Desktop/magister-calendar-master/node_modules/request/request.js:198:22)
at emitTwo (events.js:125:13)
at Request.emit (events.js:213:7)
at Request. (/Users/ksuler/Desktop/magister-calendar-master/node_modules/request/request.js:1082:10)
at emitOne (events.js:120:20)
at Request.emit (events.js:210:7)
at IncomingMessage. (/Users/ksuler/Desktop/magister-calendar-master/node_modules/request/request.js:1009:12)
at emitNone (events.js:110:20)
at IncomingMessage.emit (events.js:207:7)
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
[Proces voltooid]

That's the same error as before. Please look in your magister-calendar project folder for any crash logs.

I looked, couldnt find anything

Do you have any idea what causes this?

Please use the updated files in the crashreport-patch. See if a crash report is created now.

How to patch without chaning my config settings?

Replace your magister-calendar.js file and your assets/tools.js file with the updated files.

It still doesnt make a log

Have you re-enabled the debug setting? Please explain what you have tried and what you see.

Oh no i did not i think

Last login: Sat Jul 15 14:36:34 on ttys000
iMac-van-K:~ ksuler$ /Users/ksuler/Desktop/Calendar.command ; exit;
[] 15:8:24 Magister Calendar v1.8.3 started.
[] System Time: 15:08:24, date: Sat, 15 Jul 2017 13:08:24 GMT
[] 15:8:24 Debugging has been enabled. Extra information will be printed, and logs/dumps saved to disk.
[] 15:8:24 Using default period to fetch appointments for.
[] 15:8:24 Determined period is:
From Mon Jul 17 2017 15:08:24 GMT+0200 (CEST)
To Sat Jul 22 2017 15:08:24 GMT+0200 (CEST).
[] 15:8:24 Google OAuth2 token has expired. Requesting a new one.
/Users/ksuler/Desktop/magister-calendar-master/magister-calendar.js:217
return tools.log("critical", "Problem requesting new OAuth2 token: "+result.error.errors[0].message, result.error);
^
TypeError: Cannot read property '0' of undefined
at Request._callback (/Users/ksuler/Desktop/magister-calendar-master/magister-calendar.js:217:95)
at Request.self.callback (/Users/ksuler/Desktop/magister-calendar-master/node_modules/request/request.js:198:22)
at emitTwo (events.js:125:13)
at Request.emit (events.js:213:7)
at Request. (/Users/ksuler/Desktop/magister-calendar-master/node_modules/request/request.js:1082:10)
at emitOne (events.js:120:20)
at Request.emit (events.js:210:7)
at IncomingMessage. (/Users/ksuler/Desktop/magister-calendar-master/node_modules/request/request.js:1009:12)
at emitNone (events.js:110:20)
at IncomingMessage.emit (events.js:207:7)
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
[Proces voltooid]

https://imgur.com/a/j21nV

Do you have an idea what causes this?

A mis-configuration with your Google API setup perhaps. I have no clue unless you provide me with the error responses.

I do not get error responses

Yes, you do.
Try changing line 219 in /Users/ksuler/Desktop/magister-calendar-master/magister-calendar.js from:
tools.log("critical", "Problem requesting new OAuth2 token: "+result.error.errors[0].message, result.error);

to:
tools.log("critical", "Problem requesting new OAuth2 token: ", result);

And see what result gets printed to the console.

Done, new error log
Last login: Mon Jul 17 18:39:43 on ttys000
iMac-van-K:~ ksuler$ /Users/ksuler/Desktop/Calendar.command ; exit;
[] 21:43:34 Magister Calendar v1.8.3 started.
[] System Time: 21:43:34, date: Tue, 18 Jul 2017 19:43:34 GMT
[] 21:43:34 Debugging has been enabled. Extra information will be printed, and logs/dumps saved to disk.
[] 21:43:34 Using default period to fetch appointments for.
[] 21:43:34 Determined period is:
From Wed Jul 19 2017 21:43:34 GMT+0200 (CEST)
To Fri Jul 21 2017 21:43:34 GMT+0200 (CEST).
[] 21:43:34 Google OAuth2 token has expired. Requesting a new one.
[!] 21:43:34 Problem requesting new OAuth2 token:  {"error":"invalid_request","error_description":"Missing required parameter: refresh_token"}
[*] 21:43:34 Saved crash report to disk.
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
Deleting expired sessions...none found.
[Proces voltooid]

It seems that the application does not have the refresh_token. A solution could be to re-authenticate your Google application.

Thank you

I created a new Google API, and added the new client_secret.json file to the Magister-Calendar-Master Folder, but I still get the same error.

Did you remove the .credentials folder in your home directory? And re-authenticated the application using the first run file?

Thank you very, very much!!!
Issue is closed


Differences between slant and ray-tracing

Slant computed through projection from Zenith and that of ray-tracing on slant direction should be the same.

They can only be the same for a constant ideal weather model. This should be a unit test.

Above is ZTD projected to LOS? RAY is the ray tracing output or the difference?

Above is ZTD projected to LOS? RAY is the ray tracing output or the difference?

Sorry I had the titles mislabeled. From left to right: ZTD projected to LOS (using orbit files) output, RAY tracing output, and the difference between the two outputs (middle column - left column)

I think that may be the issue.
In the former figure, I computed height levels from -500 to 9500 m in 500 m intervals.
Here, I computed them in 100 m intervals. Also notice the difference in lower bound of colorbar

The data is right looking ascending? The rays at west (near range) are shorter because of lack of support in that case.

But if user specifies the height levels they are interpolated from the 3D cube of the model, where they are hard-coded at fixed steps. So are we missing something in the model or what is the cause for seeing water?

I mean the height levels available as part of the weather model that get used. Each ray is intersected with the model heights.
If you truncate at 30km vs 80km or use all levels provided by the model. You will need greater support for 80km than 30km.

yes i understand that part. We should add a larger spatial buffer (long lat bufer). Depending on left or rightl looking on side would need more.
I was more puzzled why the increase in number of steps in vertical would impact it. Internally we use the maximum available height in the model; when a user specifies height intervals the final cube is just re-interpolated to match the user requested heights.

Do we have a good idea of what zenith delay vs hgt profiles look like? Can we generate some of these 1D plots at 10m steps. Maybe that will inform how to space the layers - uniformly or non-uniformly etc.    10m 3D cubes might be too expensive - I feel like 100m also might be too expensive. Being smart and using a non-uniform grid in height might help possibly.

Hopefully these are helpful. The two curves per panel are different locations, about 5 km apart and 275 m elevation difference.

Thank you. These look great. My gut feeling is that for dry delay, 500m should be more than enough. For wet, there seems to be 2 regimes. One up to 3-4K or so and another higher than that. There may be some room for optimization here without having to use a dense set of heights all the way to 10K.

@bbuzz31 @jlmaurer have we close the loop on the buffering to remove the tilt like residual?


No doc attribute for pulseGeneratorDL

The dimensionless pulse generator pulseGeneratorDL cannot be located in the usual way:
doc = loaders.NeuroMLLoader.load(NML_MODEL_PATH)
my_pgdls = doc.pulse_generator_dls

There is no such attribute in the loaded doc, only one for regular pulse_generators.  It appears that the loader does not yet match the schema in this regard.  I figure these attributes are auto-generated from some list, and since nml.py is in turn generated from generateDS.py, I figure it is best if I stay out of this one.

There's no pulseGeneratorDL in the schema, and so none in libNeuroML.
It's reasonable to add this though, as it at least gives the ability to stimulate dimensionless cells etc. Most of the other infrastructure for dimensionless synapses/networks is not there as use of dimensional entities in NML2 is strongly encouraged.
Will add it and let you know.

Added to the schema in the development branch: https://github.com/NeuroML/NeuroML2/blob/development/Schemas/NeuroML2/NeuroML_v2beta4.xsd#L509 & libNeuroML has been updated.


Custom summary prompt in env functionality

Allows to put a custom summary prompt in a env variable.
I put it in a env variable because I find it more practical to change (and private if you want to push your config to your own GitHub) than putting it in config.yml.
Tested and working on Render

Thanks for this. Given the length and potential complexity of prompts, I'd prefer to see custom prompts being implemented as templates loaded from the filesystem. Multiline environment variables are a challenge to maintain.
We probably want to set up a directory structure or some other means of organization that allows us to identify which extractor (or other tool) and model the prompt is intended to be used with.
Would you be open to implementing this alternate approach? Happy to jump onto to a call to discuss the design live if it would be helpful.

Okay I put the prompts configuration directly in the config.yaml. This is the first time I write in go so please tell me if there are any changes to make to improve it

Thanks, @bricemacias. It looks like the tests are failing as the config model is misnamed. Would you like to update the PR so that the tests pass?
You can run the build and test locally:
make

You'll need to have the database and NLP services running in order for the unit and integration tests to pass:
docker compose up db nlp

Sorry I had not tested it. I did the docker build and make commands, but I don't have an anthropic api key so my local anthropic tests are failing. The rest seem to pass locally now however.
I also made a deploy on render with a custom summary prompt on the config asking to summarise in French and not in English just to test, and it's working

Moved into #211 in order to run tests.


Adding generic objects and improving presentation data

Added generic_object model for storing things like ensembles and other things.
Added a presentation_data_template model for storing data structure.
Adding support for the new presentation data editor. Once I migrate the sciences site to this I can remove all of those old YAML related methods.
Added some helper methods to the related_object_tags concern

+1


Pulse tolerance

Description
Add a tolerance to the delta_pulse_laser so python precision issues don't keep it from firing.
Todos

[x] Add tolerance

Status

[x] Ready to go

to whomever merges this PR, could you select "Squash and merge"? I had some trouble cleaning up the git history, and that will tidy things up.

Codecov Report

Merging #47 (77f7252) into main (7a1653d) will increase coverage by 0.00%.
The diff coverage is 100.00%.


Replace menu button popup content with a menu

The menu button example needs to have a menu in the popup to properly demonstrate how it should work, based on this example: https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-2/menu-button-2.html

fixed in 5ae5061c21d25962078cfea6a23c8c064eb20cb4


[Fix]: selectors always cause re-render because of always return a new function

Description
This PR contains below fixes:

selectors always cause re-render because of always return a new function: In extendSelectors#L41 always return a new function builder(state, api.get, api)[key] which cause re-render every time.
fix extendSelectors argument typo in README: Also in extendSelectors#L41 , the first arguments is state, but we named it set in README while extendActions is correct.
correct equalityFn typing: This is my missing, the equalityFn receive the current key's data structure instead of the whole store structure.

And maybe we should add more test for this library in the future.


Track graphic IDs on players via polling

The onGraphicChanged events do not trigger with players.

Resolved after a RuneLite update.


Voting for new owners between 2024/1/1 ~ 2024/12/31

to follow our rules ... (https://github.com/woodpecker-ci/woodpecker/blob/master/CONTRIBUTING.md#owners) here it goes:
@woodpecker-ci/advisors @woodpecker-ci/maintainers
Only maintainers (& advisors) are eligible to vote or to be elected, and if somebody doesn't want to be elected please send comment in this thread. Every maintainer could send 2 or less votes to other maintainers on the following comments and cannot send the votes to them self. The voting is available from now to 2023/12/31 or the point all people with vote rights have done so.

see #1467 for inspirations

What would be the benefit of it?

That doesn't make sense to me, as that's literally the idea of a yearly election... If voters are afraid to "downgrade" someone, we can just skip the election at all :shrug:

@6543 @anbraten

@pat-s you still have no valid vote :sweat_smile:

I think you guys do an amazing job. I am happy with the result you come to.

@6543 @anbraten steady as she goes :bird:

we have 7 of 9 guilty votes
6x @6543
5x @anbraten
3x @qwerty287

I do accept :) - thanks for the trust again :heart:

@anbraten do you accept?
-> #3075


use-delta-profiles not working, pull

Hi,
Try to make work the delta pprof without luck:
log-level: debug
scrape-configs:
  - job-name: testing-golang
    enabled-profiles: [cpu, mem, goroutines, mutex, block]
    use-delta-endpoints: true
    static-configs:
      - application: golang-framework-local
        spy-name: gospy
        targets:
          - 'host.docker.internal:8000'
        labels:
          env: dev

We are using Gin Framework so we had to add the router:
```
pprof.Register(router)
// Register Pyroscope delta profiler
base := "/debug/pprof"
prefixRouter := router.Group(base)
{
prefixRouter.GET("/delta_heap", gin.WrapF(deltapprof.Heap))
prefixRouter.GET("/delta_block", gin.WrapF(deltapprof.Block))
prefixRouter.GET("/delta_mutex", gin.WrapF(deltapprof.Mutex))
}

which work as in the the browser, querying  "/debug/pprof/delta_heap"  a .gz file is download for the delta heap. (like heap.pprof.gz)

But the UI/server still only query the original pprof. Targets not configured for the delta.

Are we missing something in the config?
We dont see any mention to "delta" in the terminal debug logs when starting the pyros servers.

The parameter is called use-delta-profiles not use-delta-endpoints
Feel free to reopen if it does not help

thanks... right now we have no idea from where we copied that snipe of use-delta-endpoints.


Fade scroll animations added.

Related Issue
Closes #343
Description
I have added the scroll fade in animation the pages of the website.
Kindly review and merge it under GSSOC'24.
Type of PR

[ ] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / Videos (if applicable)
https://github.com/CodeHarborHub/codeharborhub/assets/132138302/d95f3423-2c54-43df-abba-4ecf1c6cc8ce
https://github.com/CodeHarborHub/codeharborhub/assets/132138302/48e0c358-9d31-44dc-b77c-757ed5101bba
https://github.com/CodeHarborHub/codeharborhub/assets/132138302/3b665fc5-185d-4142-a7fc-02f162805388
Checklist

[x] I have performed a self-review of my code.
[x] I have read and followed the Contribution Guidelines.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[x] I have commented my code, particularly in hard-to-understand areas.

Additional Context
Used "framer-motion" library
Resources for Guidance
Here are some resources that may be helpful as you contribute to CodeHarborHub:

Code Harbor Hub Community Features
Docusaurus Documentation
React.js Documentation
Markdown Guide
MDX Documentation
Mermaid Documentation

Resources for DSA Features on Our Site:

Tabs: Switch Languages
Line Numbering
Math Equations

Make Sure you checked code for every layout or device. If something is not working then fix it. and everything is fine the change some code, and also, chane our suggestion.
Fix It;

Hey @Ajay-Dhangar I have done the suggested changes, and everything is now working fine for smaller devices also. Kindly review..


Migrate user.profile.username to user.username

I've forged a lot of progress on this in the account view as well as the user controller.

Lion's share finished, keep an eye out for hidden calls. Closing issue.


MOS

I would like to ask, the model directly outputs the MOS value at the end. During the single image test, the MOS value of some images exceeds 100. Is this normal, or is there a problem with my code?

It's possible that the model predicts out of training range values (outside
[0, 100]). This is more likely to happen for out of domain natural images,
or adversarial examples.
Best,
Vlad
On Sat, Sep 11, 2021, 10:13 w615933060 @.***> wrote:

I would like to ask, the model directly outputs the MOS value at the end.
During the single image test, the MOS value of some images exceeds 100. Is
this normal, or is there a problem with my code?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/subpic/koniq/issues/7, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAERRUZJ7QUV4U4MJK5TOEDUBMFTHANCNFSM5D2WYR7Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Sorry, I may not have made it clear. I used the koncept512 model and koniq10k database for training and testing. Is this MOS value exceeding [0, 100] normal or there are some errors in my code?

I see. It is normal that the predicted scores are within [0,100]. You can
take a look at Fig. 11 in the KonIQ-10k paper
https://arxiv.org/pdf/1910.06180.pdf .
On Sat, Sep 11, 2021 at 3:21 PM w615933060 @.***> wrote:

Sorry, I may not have made it clear. I used the koncept512 model and
koniq10k database for training and testing. Is this MOS value exceeding [0,
100] normal or there are some errors in my code?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/subpic/koniq/issues/7#issuecomment-917406773, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAERRU4A2P4ZXWUA65B6DGLUBNJVRANCNFSM5D2WYR7Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Update banner and what's new page for user research recruitment

This PR updates:

the phase banner content to support user research recruitment
the what's new page to support user research recruitment

https://trello.com/c/XgXvSu7C
⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠
Follow these steps if you are doing a Rails upgrade.

LGTM. This what is looks like


New crowdin translations

Description
For my telugu people :)
Updated strings.xml (telugu)
Checklist
Make sure you've done all the following (You can delete the checklist before submitting)

[x] Apply the AndroidStyle.xml style template to your code in Android Studio.
[x] Code is well documented
[x] Include unit tests for new functionality
[x] All user-visible strings are made translatable
[x] Code passes Travis builds in your branch
[x] If you have multiple commits please combine them into one commit by squashing them.
[x] Read and understood the contribution guidelines .

Did you do them manually ? Did you use https://translate.openfoodfacts.org/project/openfoodfacts/te# ?

Did you do them manually ? Did you use https://translate.openfoodfacts.org/project/openfoodfacts/te# ?

I have done it manually