TaskBoard_v1.0.2 stucks at "TaskBoard is Loading..."

Describe the bug
Installing the latest version, unzipping it, make API writable.
"TaskBoard is Loading..." is shown on my browser. (like on some previous versions where I already had the same issue).
I realized that unzipping the code, it is like the "src" is the folder we have to put on the webserver and not the entire directory (or point the virtualhost to the src instead of the zip root directory), is it correct ?
Thanks !

You shouldn't be using the "Source Code" downloads. Instead download the TaskBoard_v1.0.2.zip file and extract that to wherever you want TaskBoard.

:facepalm: I am a dumb !
working perfectly... sorry for the noise

I'm having the same issue using TaskBoard_v1.0.2.zip file
I'm unzipping it, making api folder writable but gets stuck in "TaskBoard is Loading..."
If I open up Web Console of Firefox it shows me this:
Loading failed for the


app.add_sub_router Not found

from robyn import Robyn, SubRouter
app = Robyn(file)
sub_router = SubRouter("/sub_router")
@sub_router.get("/hello")
def hello():
return "Hello, world"
web_socket = SubRouter("/web_socket")
@web_socket.message()
async def hello():
return "Hello, world"
app.add_sub_router(sub_router)
but add_sub_router   function not found
@sansyrox

v0.33.0

Hey @mn3711698 👋
Thanks for the issue.
It should be app.include_router(sub_router). There was a typo in the docs. I have updated it 😄

Feel free to open this issue if you have any other questions 😄


Replace mapped reads in pairs with percentage of mapped reads?

https://github.com/c-BIG/NPM-sample-qc/blob/1ea47eb7d9df3b6363c67cc9fa008e7c7a99e0de/bin/metrics/metrics.py#L28
Replace the percentage of mapped reads in pairs to reads paired or single, that are mapped

In version 0.9.0 metric pct_reads_aligned_in_pairs removed and added new metric pct_reads_mapped


Visual suggestion of list of values in tables

https://github.com/fdiwg/dcf-shiny/commit/7f0a46a7c5ed18692c958014e206a0436cdde32b


Error when exit from pipenv shell

Windows 10 x64 + python 3.6.3
λ exit
Traceback (most recent call last):
  File "c:\tools\anaconda3\lib\site-packages\pipenv\core.py", line 2107, in do_shell
    c = pexpect.spawn(
AttributeError: module 'pexpect' has no attribute 'spawn'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\tools\anaconda3\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "c:\tools\anaconda3\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\tools\Anaconda3\Scripts\pipenv.exe\__main__.py", line 9, in <module>
  File "c:\tools\anaconda3\lib\site-packages\pipenv\vendor\click\core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\vendor\click\core.py", line 697, in main
    rv = self.invoke(ctx)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\vendor\click\core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "c:\tools\anaconda3\lib\site-packages\pipenv\vendor\click\core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\vendor\click\core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\cli.py", line 281, in shell
    core.do_shell(three=three, python=python, fancy=fancy, shell_args=shell_args)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\core.py", line 2123, in do_shell
    pew.workon_cmd([workon_name])
  File "c:\tools\anaconda3\lib\site-packages\pipenv\patched\pew\pew.py", line 368, in workon_cmd
    shell(env, cwd=project_dir)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\patched\pew\pew.py", line 208, in shell
    fork_cmder(env, cwd)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\patched\pew\pew.py", line 179, in fork_cmder
    fork_shell(env, shell_cmd, cwd)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\patched\pew\pew.py", line 154, in fork_shell
    inve(env, *shellcmd, cwd=cwd)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\patched\pew\pew.py", line 137, in inve
    return check_call([command] + list(args), shell=windows, **kwargs)
  File "c:\tools\anaconda3\lib\site-packages\pipenv\patched\pew\_utils.py", line 44, in call
    return f([ex] + list(cmd[1:]), **kwargs)  # list-conversion is required in case `cmd` is a tuple
  File "c:\tools\anaconda3\lib\subprocess.py", line 291, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['C:\\Windows\\system32\\cmd.EXE', '/k', '%CMDER_ROOT%\\vendor\\init.bat']' returned non-zero exit status 1.

Are you running this inside cmder?

Yes

we dont officially support cmder, but this is probably a duplicate of #1689 so closing in favor of that

Actually it is not (at least I don’t think so because it is still reproducible after #1715). I’ll try to investigate if this is amendable, but no promises atm.

This is actually reproducible without Cmder. The thing is cmd.exe (also PowerShell, both Core or not) exits with whatever the last command it executed exited with. So this works:
> pipenv shell
(subshell) > dir /w
[directory content...]
(subshell) > exit
>

But this spits out an error:
> pipenv shell
(subshell) > meh
'meh' is not recognized as an internal or external command,
operable program or batch file.
(subshell) > exit
[long traceback]
  File "Lib\subprocess.py", line 291, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['C:\\WINDOWS\\system32\\cmd.EXE']' returned non-zero exit status 9009.
>

I don’t have a good solution but to suppress the exception.

Why don't we just move back to using a subprocess?

It won’t help in this case. Even if we use a subprocess, the subprocess of the subprocess will still report an error, which will bubble up unless we suppress it somewhere. I suspect this problem have existed all along (it affects all pew users), just never surfaced because 1. Windows users are scarce, and 2. nobody could reproduce it due to its obscure nature.


Commands to customize colors and DuckDuckGo search

I added the command duckduckgo (or only d), it works equals google but with DuckDuckGo.
I also added these commands:

textcolor - it receives an arg with the color that you want to set text color
bgcolor - it receives an arg with the color that you want to set the page background color
promptcolor - it receives an arg with the color that you want to set prompt color
All these commands save the changes with cookies.

@OrlatoDev Do you mind if I use some of your code in my fork?

@OrlatoDev Do you mind if I use some of your code in my fork?

No problems dude, you can use

Thank you!


lint: add more linters for using absl:: over std::

Follow up to https://github.com/envoyproxy/envoy/pull/13040. Some of these examples are based on absl docs and C++ docs.
These linters are here to prevent additional breakages of Envoy Mobile on iOS due to usages of std:: types/functions that are not supported on iOS 11. More discussion in https://github.com/envoyproxy/envoy/issues/12341.
Risk Level: Low
Testing: In PR
Signed-off-by: Michael Rebello<EMAIL_ADDRESS>

Sorry, format check fails and run ci/run_envoy_docker.sh 'ci/do_ci.sh fix_format' to fix it.

LGTM modulo format fix.

Thanks. Running the docker command didn't work for me but I fixed locally and pushed

Also, while you are in here did we ever add a linter for string_view? We need that also.

Done, added additional linters / test cases.

Hm, looks like there are a lot of usages of std::get in the codebase today, which is why the linter is failing. Are you sure we need that one @ggreenway?

Hm, looks like there are a lot of usages of std::get in the codebase today, which is why the linter is failing. Are you sure we need that one @ggreenway?

Huh, std::get is used for both tuples and variants. We want to lint for only the uses with variant, not tuple, probably. But that's well into the realm of needing clang-tidy. So for now, I'd say remove the std::get one.

Sounds good, removed.

Looks like we also have existing usages of string_view which don't seem to be breaking Envoy Mobile @mattklein123: https://dev.azure.com/cncf/envoy/_build/results?buildId=50922&view=logs&jobId=9fd74226-df5b-5f29-39da-76fc341cc763&j=9fd74226-df5b-5f29-39da-76fc341cc763&t=068b98b1-acf0-52d0-fc6e-f6d1a5b1d5ef

@rebello95 looks like those uses are all in extensions code we don't include/compile into Envoy Mobile. Hence why they are in the codebase here but causes no trouble to Envoy Mobile.
But yes, the decision was to not use std::string_view, so the linter change here to prohibit it is great, thanks!

Thanks for confirming @junr03! I pushed a change to fix the violations from the main branch.

Coverage failure looks unrelated

I think coverage on main branch is broken somehow due to recent limit changes. I will merge this and we can sort it out there.

Thanks!


(DOCS) PDB 6.9.1 release notes

This commit adds one new feature release note.

CLA signed by all contributors.


Add link to LF trademark usage

Context:

https://clomonitor.io/projects/open-telemetry/open-telemetry#community_legal:

Checks reference documentation

I'd like to repeat what I did for [gRPC], and add linuxfoundation.org/trademark-usage to the footer:

This might require upstreaming the gRPC footer changes.
/cc @caniszczyk

Would it also make sense to add the marketing guidelines (https://github.com/open-telemetry/community/blob/main/marketing-guidelines.md) to the footer as well? They're kinda buried right now.

🙃 the limitations of iconography I suppose

this seems to be still relevant?

Legal status is now green in CLOmonitor, https://clomonitor.io/projects/cncf/open-telemetry#community_legal, closing.


[VL] minor change for fallback log

What changes were proposed in this pull request?
Add query id to fall-back log. When there are many queries in same application, we can easily to trace the fall-back ops.

@ulysses-you , could you help check this?
Thanks.

@zhli1142015  it seems the failed test is relevant, can you check it ?
12:40:05  - test fallback logging *** FAILED ***
12:40:05    testAppender.loggingEvents.exists(((x$1: org.apache.logging.log4j.core.LogEvent) => x$1.getMessage().getFormattedMessage().contains("Validation failed for plan: Scan parquet default.t, due to: columnar FileScan is not enabled in FileSourceScanExec"))) was false (GlutenFallbackSuite.scala:39)

@zhli1142015 it seems the failed test is relevant, can you check it ?
12:40:05  - test fallback logging *** FAILED ***
12:40:05    testAppender.loggingEvents.exists(((x$1: org.apache.logging.log4j.core.LogEvent) => x$1.getMessage().getFormattedMessage().contains("Validation failed for plan: Scan parquet default.t, due to: columnar FileScan is not enabled in FileSourceScanExec"))) was false (GlutenFallbackSuite.scala:39)

Thanks, looking.

===== Performance report for TPCH SF2000 with Velox backend, for reference only ====

query
log/native_3919_time.csv
log/native_master_12_04_2023_94c91c55d_time.csv
difference
percentage

q1
35.22
34.65
-0.566
98.39%

q2
25.38
24.91
-0.475
98.13%

q3
37.55
36.38
-1.171
96.88%

q4
37.99
37.37
-0.626
98.35%

q5
71.64
72.63
0.986
101.38%

q6
8.01
6.87
-1.139
85.78%

q7
84.30
85.44
1.140
101.35%

q8
86.99
87.86
0.875
101.01%

q9
127.85
124.52
-3.328
97.40%

q10
46.00
46.04
0.040
100.09%

q11
20.35
20.12
-0.223
98.90%

q12
23.46
26.71
3.244
113.83%

q13
45.74
46.45
0.709
101.55%

q14
18.37
14.55
-3.825
79.18%

q15
26.95
28.16
1.209
104.49%

q16
15.59
15.75
0.163
101.05%

q17
102.70
103.10
0.408
100.40%

q18
149.46
150.63
1.172
100.78%

q19
13.01
12.90
-0.113
99.13%

q20
28.07
27.73
-0.342
98.78%

q21
222.40
222.80
0.395
100.18%

q22
13.24
13.06
-0.186
98.60%

total
1240.28
1238.63
-1.651
99.87%


Feature/stacked update

First pass at upgrading to new stacked arch

You can continue working on this if you would like. The immutable state wasn't working out. Needs more planning.


[Outlook] (API error codes) Add error code 9020 and troubleshooting link

Update API error code list in response to Issue #3214.

Docs Build status updates of commit 7c08c72:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/javascript-api-for-office-error-codes.md
:white_check_mark:Succeeded
View

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

Docs Build status updates of commit 2f38b64:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/javascript-api-for-office-error-codes.md
:white_check_mark:Succeeded
View

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


K8SPXC-1293: Fix binlog replay if proxy protocol enabled

CHANGE DESCRIPTION
Problem:
Binlog recoverer stuck if proxy protocol enabled.
Solution:
Use admin port.
CHECKLIST
Jira

[ ] Is the Jira ticket created and referenced properly?
[ ] Does the Jira ticket have the proper statuses for documentation (Needs Doc) and QA (Needs QA)?
[ ] Does the Jira ticket link to the proper milestone (Fix Version field)?

Tests

[ ] Is an E2E test/test case added for the new feature/change?
[ ] Are unit tests added where appropriate?
[ ] Are OpenShift compare files changed for E2E tests (compare/*-oc.yml)?

Config/Logging/Testability

[ ] Are all needed new/changed options added to default YAML files?
[ ] Are the manifests (crd/bundle) regenerated if needed?
[ ] Did we add proper logging messages for operator actions?
[ ] Did we ensure compatibility with the previous version or cluster upgrade process?
[ ] Does the change support oldest and newest supported PXC version?
[ ] Does the change support oldest and newest supported Kubernetes version?

Test name
Status

We run 0 out of 36

commit: https://github.com/percona/percona-xtradb-cluster-operator/pull/1505/commits/ad58122b6e258fd8fd3e8abb8156621cd0f80368
image: perconalab/percona-xtradb-cluster-operator:PR-1505-v1.12.0-9-gad58122b


Can't edit device.

Hello. :)
I've got a problem with the home app. Whenever I add a new accessory, it will be shown in home but I can't edit the name/room. The app just keeps telling me that I cant edit the device. Anyone knows what the problem can be?
Edit: I can edit some accessories. Like 1 out of 5

Have you tried to rm -rf persist and rm -rf persist-plugins first, then restart your homebridge? This happened to me several times, and this method works for me.

Restarting the iPad also solves the problem :)


Register citybook.io as domain name, update CNAME and A records

citybook.io has been purchased on google domains and is currently forward to codeforamerica.github.io/citybook. Because this domain includes a path, we can't link directly from Google Domains. Need to migrate everything to heroku and configure domain there.


Show cycle number in more visible place

The cycle/tossup number is only visible in the event log. It should be visible either in the tossup text or above the scoreboard.
This fork does this: https://github.com/hdwhite/nsc_livestats

Need to look at this again; the question number is between the Previous/Next buttons. The one difference I could see is the tossup number in the packet; maybe that could go with the question metadata since it's not generally relevant?

The bonus number should also be visible so it's easier to refer to it for things like protests.


[TACHYON-470] Fix TachyonConf.getInt to take no default value

JIRA: https://tachyon.atlassian.net/browse/TACHYON-470
Current getInt takes a default value. This PR aims to update all occurrences of this method and remove the call with the default value parameter.
This PR also adds a few default properties into tachyon-default.properties and set some to -1 indicating null

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4366/
Test PASSed.

Thanks @apc999 ! I left a few questions in the review.

@gpang , could you take another look? I revert the change to the properties file but comment more in the code, in this way, this PR changes less about the current behavior. We can for sure think about more how to address these properties if they can not be defined as constants, but maybe not in this PR (and JIRA).

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4393/Failed Tests: 2org.tachyonproject:tachyon-common: 2tachyon.util.network.GetMasterWorkerAddressTest.getWorkerAddressTesttachyon.util.network.GetMasterWorkerAddressTest.getMasterAddressTest
Test FAILed.

Jenkins, test this please.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4395/
Test PASSed.

LGTM

@apc999 so after applying the PR, if I wanna introduce a parameter, I only need to define one in tachyon-default.properties, am I right?

@tianyin , correct, that is the purpose of TACHYON-470---to centralize configurations.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4432/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4431/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4433/Failed Tests: 2org.tachyonproject:tachyon-common: 2tachyon.util.network.GetMasterWorkerAddressTest.getWorkerAddressTesttachyon.util.network.GetMasterWorkerAddressTest.getMasterAddressTest
Test FAILed.

@apc999 this is absolutely good. The getXXX(key, default) interface probably comes from Hadoop's getter style. (Just for my own curiosity) do you know why they design the getter functions like this?

@tianyin , emm, sorry I am not aware of the historical reason for this style of getters :)

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4435/
Test PASSed.

@apc999 could you resolve the conflicts please?

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4511/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4512/Failed Tests: 1org.tachyonproject:tachyon-integration-tests: 1tachyon.master.JournalShutdownIntegrationTest.multiMasterJournalCrashIntegrationTest
Test FAILed.

Jenkins, test this please.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4513/
Test PASSed.

@calvinjia, can you take another look?

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4558/
Test PASSed.

LGTM


Recommendations for 'ljmo', 'vjmo', and 'tjmo' contradict the Hangul script development spec

'ljmo' is documented thus:

Recommended implementation: The 'ljmo' table maps the sequence required to convert a series of jamos into its leading jamo form (GSUB lookup type 4).

'vjmo' and 'tjmo' are documented similarly. This contradicts the Hangul script development spec, where 'ccmp' is responsible for converting a sequence of simple jamo into a single complex jamo (e.g. <pieup, sios, thieuth> into pieup_sios_thieuth), and 'ljmo', 'vjmo', and 'tjmo' are recommended for contextually replacing single jamo glyphs. I suggest:

Recommended implementation: The 'ljmo' table maps a jamo into its leading jamo form (GSUB lookup type 5).

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 61a9106c-ca98-1891-2c00-ace78615994f
Version Independent ID: 0feefbc8-23a7-5bc8-76dc-0a336a1c7968
Content: Registered features, k-o - Typography
Content Source: typographydocs/opentype/spec/features_ko.md
Product: typography
GitHub Login: @PeterCon
Microsoft Alias: PeterCon

Similar issues for 'vjmo' and 'tjmo'.

I don't think type 5 should be mentioned: an implementation might do contextual analysis in a shaping engine vs. doing contextual analysis in lookups. The general philosophy in the original OT design was don't repeat in fonts logic that would be common across fonts. Either way, that should be sorted out in a shaping spec.

Actually, type 5 (or perhaps 6) is really going to be needed (if nothing else, forms for LV vs. LVT syllables need to be distinguished). But I don't think it needs to be prescribed here.

Changed for next version:
'ljmo':

Recommended implementation: The 'ljmo' table maps the sequence required to convert a series of jamos into its leading jamo form (GSUB lookup type 4)a default glyph for a leading jamo into into the form required for conjoining in a syllable.

'tjmo':

Recommended implementation: The 'tjmo' table maps the sequence required to convert a series of jamos into its trailing jamo form (GSUB lookup type 4)a default glyph for a trailing jamo into into the form required for conjoining in a syllable.

'vjmo':

Recommended implementation: The 'vjmo' table maps the sequence required to convert a series of jamos into its vowel jamo form (GSUB lookup type 4)a default glyph for a vowel jamo into the form required for conjoining in a syllable.


The application drops too many frames in debug mode

The release mode works smoother but it is still concerning.
During the latest Android Worldwide social hours Robb told that they don't use setState in their commercial code base on purpose. According to him setState rebuilds the whole widget. In my opinion the rebuild is still optimized and child widgets won't be rebuilt if their state is the same and other factors won't force (for example visual partial overlay by other widget). But this might be a way to improve.
One way to eliminate setState is to use the Google endorsed Provider pattern and maybe also BLoC. Someone told me it is basically an InheritedWidget (I'm just brain dumping what I've heard).

There was a very inspiring talk by Code Koalas https://www.meetup.com/Code-Koalas-Workshop-Wednesday/events/284397578
Example repo: https://github.com/ArneSaknussemm89/freegamesapi
Uses BloC pattern + https://pub.dev/packages/graph_bloc + River Pod. Also uses for non mutability https://pub.dev/packages/freezed
This is the way to go

Flutter Luxemburg meetup: TiQuest uses https://pub.dev/packages/fl_chart it has more likes, and maybe faster than  https://pub.dev/packages/charts_flutter (our older library https://google.github.io/charts/flutter/gallery.html) or our current https://pub.dev/packages/syncfusion_flutter_charts
The question is if it has all the required features, most importantly color configuration, range coloring and configuration

Flutter Scotland's State Management Extravaganza:

https://twitter.com/RydMike/status/1528827017172504579

Our architecture is not reactive, Provider / RiverPod author disadvise Provider and suggests RiverPod. Maybe also BLoC!

https://slides.com/mhadaily/architectural-thinking-on-flutter-state-management

https://youtu.be/pdKb8HLCXOA?t=6936
Inherited Model, aspect oriented approach of updates:
I have the Record stub which has 6+ measurements
Each item of the fixed list view listens on one specific measurement only of the model. So I should use select of RiverPod (Provider also has), so the widget only updates by that specific measurement.

RiverPod vs BLoC article: https://medium.com/@NALSengineering/flutter-riverpod-or-bloc-7-reasons-why-i-did-not-choose-riverpod-e954bed59e2f


Misc web updates

Updates to the about page for representation list and representatives that have aged off.
Updates to accessibility in an attempt to close #267.
Feedback welcome!

Does anyone know how I can view the URL to the website from this branch?


hoster: remove allow_untrusted

==> Standard Output of failed command:
installer: Cannot install on volume / because it is disabled.
installer: version check failure. to install require MacOSX 10.4.4 later.


clear password if user type wrong passwords

When user tries to login with wrong password, there will be a toast popping up and reminding user that this is a wrong password. But the wrong password still remains in the field. It will be nice to clear it automatically so that user can directly try with new password

fixed


[loc][Query][VSCode] Please clarify localizability for words in quotes

Hi, we have a question from our translator. Can you help please? Thanks!
Source:
Controls the wrapping column of the editor when editor.wordWrap is 'wordWrapColumn' or 'bounded'.
File Name:
src\vs\editor\common\config\commonEditorConfig.nls.resx
Resource ID:
".resx", 0; "wordWrapColumn"
Query:
Please confirm if the parts in quotes should be localized or not. We assume that editor.wordWrap and 'wordWrapColumn should not be localized, but what about 'bounded'? Thanks!

Also 'bounded' should not be localized. I have pushed a commit that adds comments to clarify these strings. Thank you!


"Unable to extract next.js data" when trying to download TED talk

Checklist

[X] I'm reporting a broken site
[X] I've verified that I'm running yt-dlp version 2022.01.21. (update instructions)
[X] I've checked that all provided URLs are alive and playable in a browser
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[ ] I've read about sharing account credentials and I'm willing to share it if required

Region
Finland
Description
When trying to download TED talks (e.g. https://www.ted.com/talks/thomas_thwaites_how_i_built_a_toaster_from_scratch but the same issue manifested also with arbitrary ones I tried from the front page), I get the error that yt-dlp is unable to extract the next.js data. I presume this is due to the format of next.js having changed.
I found a #2343 which appeared relevant, but that was marked fixed. The new TED extractor that fixed that issue was merged 6 days ago (#2359), and so I presume would be in 2022.01.21 which I am using.
Verbose log
[debug] Command-line config: ['-vU', 'https://www.ted.com/talks/thomas_thwaites_how_i_built_a_toaster_from_scratch']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, err utf-8, pref UTF-8
[debug] yt-dlp version 2022.01.21 [f20d607b0] (zip)
[debug] Python version 3.8.10 (CPython 64bit) - Linux-5.4.0-96-generic-x86_64-with-glibc2.29
[debug] exe versions: ffmpeg 4.2.4, ffprobe 4.2.4, rtmpdump 2.4
[debug] Optional libraries: Cryptodome, secretstorage, sqlite
[debug] Proxy map: {}
Latest version: 2022.01.21, Current version: 2022.01.21
yt-dlp is up to date (2022.01.21)
[debug] [TedTalk] Extracting URL: https://www.ted.com/talks/thomas_thwaites_how_i_built_a_toaster_from_scratch
[TedTalk] thomas_thwaites_how_i_built_a_toaster_from_scratch: Downloading webpage
ERROR: [TedTalk] thomas_thwaites_how_i_built_a_toaster_from_scratch: Unable to extract next.js data; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.
  File "/home/nortti/bin/yt-dlp/yt_dlp/extractor/common.py", line 612, in extract
    ie_result = self._real_extract(url)
  File "/home/nortti/bin/yt-dlp/yt_dlp/extractor/ted.py", line 48, in _real_extract
    talk_info = self._search_nextjs_data(webpage, display_id)['props']['pageProps']['videoData']
  File "/home/nortti/bin/yt-dlp/yt_dlp/extractor/common.py", line 1550, in _search_nextjs_data
    self._search_regex(
  File "/home/nortti/bin/yt-dlp/yt_dlp/extractor/common.py", line 1186, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)

Sigh, it seems that TED has decided to revert only their talks page back to the old one. You can use  yt-dlp 2021.12.01
to download talks for now.
Playlist and series use the new format but the extractor fails at the individual video extraction step.

TED has switched back to the new version and the new extractor is working again.

https://github.com/ytdl-org/youtube-dl/issues/30561

Closing since it's working now. Can re-open (and add fallback in code) if it happens again


Implement One option for imports_granularity

This implements a new option One for imports_granularity, which merges all imports into a single use statement as long as they have the same visibility.
Resolves #4669

Thank you for the PR @magurotuna! As you may have noticed the PR queue is a bit backed up at the moment as I've been preoccupied with some maintenance work and trying to get rustfmt back and available on nightly again. Should have bandwidth to get through some of these PRs in the near future though!

@calebcartwright Alright, no rush :)

Thanks again for the updates @magurotuna! I've done a quick pass through the updated implementation and agree that this could work.
Would you do me a favor though and rebase on the latest from master? There's been a lot of moving changes around this part of the codebase, as well as some forced updates of the rustc-ap crates that I'd like to have pulled into this PR before doing a final review and merge

@calebcartwright
Sure! I've done with rebasing.

Brilliant thank you!

I was looking for a config option that merges all imports.
The One option is not mentioned in the doc:
https://github.com/rust-lang/rustfmt/blob/master/Configurations.md#imports_granularity
But it's already fully implemented & merged, right?

Hm no, it's not working:
Error: Decoding config file failed:
unknown variant `One`, expected one of `Preserve`, `Crate`, `Module`, `Item` for key `imports_granularity`
Please check your config file.

When will it be available? :)

@Boscop looks like it was merged into 2.0 experimental branch, not into current master 😕
cc @calebcartwright


TypeError: Cannot read property 'D:multistatus' of undefined

Trying to get events from zoho calendar using CalDav in node.js. Could you please help me in resolving this issue? I am using node-caldav-mod plugin which is being forked from node-caldav.
Here is the issue I mentioned on stackoverflow :
https://stackoverflow.com/questions/46738962/how-to-read-and-get-events-from-zoho-calendar-using-caldav-in-node-js

You are using the node-caldav-mod fork, not node-caldav:
var caldav = require("node-caldav-mod");

This original module actually looks better (seems to use a proper namespace aware XML parser, which the fork lacks).

I tried to use that one as well but I am getting this error:
Parsing.....
Error parsing response
TypeError: Cannot read property 'D:multistatus' of undefined
Now it is reading the events from the calendar but not parsing it.
Plus I tried to add the events to the calendar that doesn't seem to be working. I want to know one more thing the URL which is being mentioned in the module is the ical one or the caldav events one? As for reading when I used caldav events URL that doesn't give me any output.

Can you tell me how to get Caldav URL to use it to get and add events? Seems like my code is working fine now just need to send the get the events to caldav URL

Hi  @helje5 I tried to use this module itself but it is not reading the events from the caldav URL in the http response, instead it is reading the events from ical URL. Could you suggest me what could be wrong?


Tiles on ListParts

I can't get tiles to work in list parts - are you sure tiles are really supported for those pages?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 40fb1c6f-690d-f75e-8980-b2e81b01f7c1
Version Independent ID: 82261d08-c471-e886-38c3-126c715cd859
Content: Display Data as Tiles - Business Central
Content Source: dev-itpro/developer/devenv-lists-as-tiles.md
Service: dynamics365-business-central
GitHub Login: @jswymer
Microsoft Alias: solsen

Hello,
Unfortunately, tiles will not work on a ListPart type page. The documentation is incorrect and it will be updated. Sorry for the inconvenience. Thanks for the feedback!


Relative library paths in GenIdea, and a relative COURSIER_CACHE on WSL2

This should allow the GenIdea output XML files to be usable cross-platform, e.g. we could resolve them on a WSL-Ubuntu environment and load them into Intellij on the host Windows machine
Tested locally on OS-X, seems to work. TBD testing it on Windows WSL2 as well

Could you please check that you can still run projects from within IntelliJ with a relative path setup. I seem to remember trying to do this in the past and there was some gotcha - however I could be mistaken.


ObjectID is not internal PDF ObjectID depending on PDF open mode

For example, when I open a Form-Fill PDF, take this as an example: https://www.irs.gov/pub/irs-pdf/f1040.pdf
Depending on if I use PdfDocumentOpenMode.Modify, or PdfDocumentOpenMode.ReadOnly, a specific field I am looking for has a different ObjectID. Note, I get the correct Object ID when using "ReadOnly" mode.
I am viewing ObjectID's using CosEdit, and I can reproduce this issue when printing out the AcroForm field ObjectID's when opening the PDF file in different modes.

This is by design.
Objects should be addressed by Name, not by ID.


statecharts, scxml, xstate - similar projects?

at first sight, cyclejs reminds of finite state machines, as declared in statecharts / scxml / xstate
maybe we can connect these projects?
xstate-viz is a neat visualizer for state machines
statecharts → https://statecharts.dev/resources.html

There are some minor similarities, but a lot of differences too. Doesn't make sense to "connect" them.


Fix save dsc dependency implementation

Fixes #581

This change is

Reviewed 4 of 4 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

@raghushantha Thanks!


expose lodash/fp on console [SATURN-1238]

Previously, the _ in the console pointed to the base lodash, rather than lodash/fp, which was confusing and unhelpful. This exposes lodash/fp instead, so we can use it for debugging.

I didn't track down what was exposing it, but I clicked around and verified that nothing seemed broken after the change.

Pete brings up a good point, and I think it would be good to track down. If we miss this now and it does affect some corner of the app that we didn't detect, it's going to be difficult to track down the cause later. For example, maybe it's IGV.js or the markdown editor or (more likely) some other obscure corner of the app.
Would it be useful to expose it as something other than window._?


Link to Screenplay Pattern video is broken

The link to the screenplay video on the main index.rst page is broken as it leads to an account that has been deleted.

Oh no! It looks like that account is gone. I can't find anywhere else that video is hosted, either.
Thanks for calling this out @emanlove, i guess i'll link to Antony's original blog post instead. :(

Thanks again! I found a link to the slides from the presentation instead, which is at least second-best. The docs have been updated to include that.


vanguards: init at 0.3.1

add derivation for vanguards, a set of scripts that increase security for tor hidden services by protecting against guard discovery attacks
resources:
https://github.com/mikeperry-tor/vanguards
https://spec.torproject.org/vanguards-spec/index.html?highlight=vanguards
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Thank you for your time reviewing my PR and your feedback.
I tried sticking to both:

https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md
https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md

I see that I should have spent more time looking at other PRs from more experienced members and will start to do so.

Please follow the CONTRIBUTING.md guide for how to make a PR to nixpkgs. I admire your first attempt, however as it is this cannot be merged.

Thank you for your time reviewing my PR and your feedback.
I tried sticking to both:

https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md
https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md

I see that I should have spent more time looking at other PRs from more experienced members and will start to do so.


feat(esdoc-publish-html-plugin): Add directory matching for SingleDocBuilder

Currently ESDoc is putting all non-member functions, variables, and typedefs into the same "KIND/index.html" folder. This can lead to conflicts when module A exports the same function as module B.
This fix allows ESDoc to build non-member single pages based on the file paths for better documentation separation.
Example:
./moduleA.js -> exports async function configure();
./pluginB/moduleB.js -> exports async function configure();
Before:
This would put both configure() functions in "docs/function/index.html"
Now:
Two files are created, each now containing the correct configure() function:
./docs/function/index.html: Lists moduleA configure()
./docs/pluginB/function/index.html: Lists moduleB configure()

Currently this only supports variables, functions, and typedefs.
If two classes were to contain the same name, conflicts could occur as well even though they could be contained in different directories.
Example Conflict:
./classA.js -> export class A {}
./pluginB/classA.js -> export class A {}
Would we want to add support to break apart all definitions by directories?

Added "organizePaths" plugin option which defaults to true. False results in the original behavior. Tests support both options.

For now, I don't have the plan to changing directory structure.


Vision Competition Ready Code

What this PR does
What does it fix/add?
Reference issues with "Fixes #10" or "Closes #10", where #10 is the number assigned to the issue

Is this related to #117?

Not really, this is just the code for the tinkeboards that can be used at competition. The auto code for it is soon to come


Harden the GitHub Workflows

This patch improves security around GitHub Workflows:
For the format.yml workflow:

Set the default workflow permissions to read - because this workflow does not need to modify anything in the project.
Do not let actions/checkout persist (write to disk) the GitHub token - because this workflow does not need to modify anything in the project. And prevents other actions to look at the token.
Remove the env:  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} section - this shares the token with every step. It is better to only do this on a per-step basis.

I am trying to understand the other two workflows. Both of those have the GITHUB_TOKEN and S3 tokens shared globally with all jobs, which doesn't feel right. This is simple to fix but I see a note on top of both ci.yml and clean.yml that those workflows are generated. There are some opportunities there to limit the risk of secret leaking, but it would mean I have to modify those files.
What do you think @mdedetrich ?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 75.683%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
277

Relevant Lines:
366

💛  - Coveralls

Thanks for the PR!

I am trying to understand the other two workflows. Both of those have the GITHUB_TOKEN and S3 tokens shared globally with all jobs, which doesn't feel right. This is simple to fix but I see a note on top of both ci.yml and clean.yml that those workflows are generated. There are some opportunities there to limit the risk of secret leaking, but it would mean I have to modify those files.

You are correct, these files are generated by the following plugin. There is also documentation for this here. On first glance GITHUB_TOKEN might be a bit complicated to fix but with the S3 tokens these should only be needed for the build/test step, I just quickly checked and https://github.com/aiven/guardian-for-apache-kafka/blob/main/build.sbt#L411 has an env argument so changing it to something like
ThisBuild / githubWorkflowBuild := Seq(
  WorkflowStep.Sbt(
    List("clean", "coverage", "test"),
    name = Some("Build project"),
    env = Map(
      "ALPAKKA_S3_REGION_PROVIDER"                   -> "static",
      "ALPAKKA_S3_REGION_DEFAULT_REGION"             -> "us-west-2",
      "ALPAKKA_S3_AWS_CREDENTIALS_PROVIDER"          -> "static",
      "ALPAKKA_S3_AWS_CREDENTIALS_ACCESS_KEY_ID"     -> "${{ secrets.AWS_ACCESS_KEY }}",
      "ALPAKKA_S3_AWS_CREDENTIALS_SECRET_ACCESS_KEY" -> "${{ secrets.AWS_SECRET_KEY }}"
    )
  ),
  WorkflowStep.Sbt(List("docs/makeSite"), name = Some("Compile docs"))
)

Along with removing https://github.com/aiven/guardian-for-apache-kafka/blob/main/build.sbt#L400-L406. Then running sbt githubWorkflowGenerate should regenerate the ci.yaml with the correct scopes.
If you are happy  to try this out then go ahead otherwise you can just mark this PR for ready + I will merge it and I then can try fixing the GITHUB_TOKEN/S3 in another PR.

I also just noticed https://github.com/djspiewak/sbt-github-actions/pull/97, with regards to GITHUB_TOKEN maybe this is related?

I put this one up for review. Lets land this one first and then figure out what to do with the generated workflows. It may be better to submit a patch to the sbt-github-actions project to ask for better token handling. I'm happy to investigate that separately from this PR.

Thanks for the contribution! I will also do a PR for the S3 keys as stated at https://github.com/aiven/guardian-for-apache-kafka/pull/186#issuecomment-1089450741.

I made a pull request at https://github.com/aiven/guardian-for-apache-kafka/pull/206 with the proposed solution at https://github.com/aiven/guardian-for-apache-kafka/pull/186#issuecomment-1089450741. The only outstanding thing to consider is the GITHUB_TOKEN issue.


Rewrote most of the JS integration.

There were several corner cases that were not well addressed with the
old code and attempting to tweak it just resulted into a wack-a-mole
situtation.
Main Integration (address-verification.js.coffee)
The main integration has been simplified to do the following things:

When the page is loaded the plugin is intiailized
There is a public method to disable the verification on an address
given any field from that address.
There is a public method to re-enable the verification on an address
given any field from that address.

The smarty_disable function can be just for a moment (for example
when shipping is hidden or show) or it can be made permanent if the
optional second argument is true. The reason to permanently disable is
that there are certain situtations where the plugin reaches a state
where it fails to work and there is no way to get it working again.
Tather than it end up in that broken state we actively disable it
proactively.
The primary use case of this permanent disable is when the country
changes. The plugin cannot deal with the state options being swapped
out. When this happens it will always blank out the state causing the
address save to always fail. The primary situtation this would happen
is when the address is Canada and we want to edit it to be US. Switching
to US previously re-enabled the plugin. Now we leave it disabled even
though we should be able to validate the address. Server-side validation
is still in place.
This primary use case is account for in this commit. The main integration
checks for non-US address during load.
Overrides
To make the plugin work better with Spree there is a bunch of Spree
functionality we tweak. It is as follows:

If we think the country got changed (due to the states being updated)
we permanently disable the validation (even if the country became US)
due to the previously mentioned plugin bug with state options. The
states are loaded in two different ways (one for the frontend and one
for the backend). This decorates both state updates.
The select2 functionality is disabled on the state dropdown. The plugin
cannot deal well with it. It also hooks into the state updates as Spree
will try to re-initialize select2.
If the "Use Billing" option is selected we tweak Spree so that it will
enable/disable the validation (not permanently) so we don't get validation
errors on the hidden field which may or may not be valid but it doesn't
matter.
When a customer is selected on an order in the backend we send a change
event as the plugin doesn't actively monitor the fields but instead listens
for the change event which spree does not send by default.

Looks good! :+1: Inline comments are a huge help, thanks for documenting every step of the way!

The inline comments are so I remember why the heck all those hacks are in there 6 months down the road. :)


[nit] SyncUntil does not mention in its name it only matches key on arrays

Initially i thought that this function was generic enough to just match key and throw that variable into the check function, but turns out that's not the case.
I suggest renaming it to SyncUntilArray, and adding a generic function SyncUntil which does above expected behaviour.

https://github.com/matrix-org/complement/pull/272


simplify normalizing

Current coverage is 100% (diff: 100%)

Merging #2339 into master will not change coverage

@@           master   #2339   diff @@
=====================================
  Files          61      61
  Lines        1267    1267
  Methods         0       0
  Messages        0       0
  Branches        0       0
=====================================
  Hits         1267    1267
  Misses          0       0
  Partials        0       0

Powered by Codecov. Last update c3aa263...c3f8fee


Conditional for enabling/disabling the security-hub module entirely

As a developer, I want to be able to disable the security-hub module with all its resources, so I can include it in a multi-workspace setup where the security-hub is created only in the workspace that relates to my AWS master account, while all other security-related modules are deployed in all accounts i.e. all workspaces.

This is done in master branch now. We will include this in the next release / tag as well.

This is done in master branch now. We will include this in the next release / tag as well.


Obsolete documentation about playfab authentication with google play games

This documentation uses API that is no longer available in the google play plugin version 0.11.1
Please see this document for the breaking changes:
https://github.com/playgameservices/play-games-plugin-for-unity/blob/master/UPGRADING.txt

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 74bf3716-f9bc-237b-395b-c61eb5c91dbf
Version Independent ID: 7e7bcfee-80a6-760d-76ab-bd779160cf43
Content: PlayFab authentication with Google Play Games Sign-In in Unity - PlayFab
Content Source: playfab-docs/features/authentication/platform-specific-authentication/google-sign-in-unity.md
Product: playfab
GitHub Login: @joannaleecy
Microsoft Alias: joanlee

Apologies for the lack of response and thank you for taking the time to report the problem. We are doing a full review of this page for required updates.

— Travis

From: Adam Skewgar @.>
Sent: Saturday, November 11, 2023 5:24 PM
To: MicrosoftDocs/playfab-docs @.>
Cc: Travis Bradshaw @.>; Assign @.>
Subject: Re: [MicrosoftDocs/playfab-docs] Obsolete documentation about playfab authentication with google play games (Issue #366)
Apologies for the lack of response and thank you for taking the time to report the problem. We are doing a full review of this page for required updates.
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/playfab-docs/issues/366#issuecomment-1806967323, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP5UHIN7KNVVVYQOX2RT2BTYEAQMHAVCNFSM6AAAAAARMM7LRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWHE3DOMZSGM.
You are receiving this because you were assigned.Message ID: @.***>

@.*** would like to recall the message, "Re: [MicrosoftDocs/playfab-docs] Obsolete documentation about playfab authentication with google play games (Issue #366)".

Page has been updated. Please let us know if you have any further feedback. Thanks!


Cannot communicate through outgoing-interface if default gateway is not on the same interface

Description:
unbound cannot communicate through outgoing-interface IP if default gateway is not on the same interface.
I'm trying to route unbound through OpenVPN (client) without the tunnel being set as the default gateway on the system. I want traffic only selectively to pass through the VPN tunnel (tun0). To achieve this, I prevent the OpenVPN server from setting the default gateway by adding this line the OpenVPN client config file:
pull-filter ignore redirect-gateway.
This successfully stops OpenVPN from modifying the ip routing table to force all traffic through the VPN tunnel. Applications can selectively choose to use the tunnel or not. I've tested that this works with both ping and curl with the current settings.
I can get the public IP of the VPN server like so:
curl <IP_ADDRESS> --interface tun0
And to get the public IP of my ISP:
curl <IP_ADDRESS>
(<IP_ADDRESS> is checkip.dyndns.org. I'm using the server's IP address instead of the domain because during this test the DNS, unbound, is not working.)
Ping also communicates through the tunnel or not by specifying -I tun0 or -I enp0s3.
With unbound running:
dig google.com
;; communications error to <IP_ADDRESS>#53: timed out
;; communications error to <IP_ADDRESS>#53: timed out
;; communications error to <IP_ADDRESS>#53: timed out
; <<>> DiG 9.18.18-0ubuntu<IP_ADDRESS>-Ubuntu <<>> google.com
;; global options: +cmd
;; no servers could be reached
Unbound conf file:
server:
interface: <IP_ADDRESS>
interface: <IP_ADDRESS>
# This is the IP of tun0
outgoing-interface: <IP_ADDRESS>
port: 53
access-control: <IP_ADDRESS>/8 allow
access-control: <IP_ADDRESS>/8 allow
access-control: <IP_ADDRESS>/16 allow
do-ip4: yes
do-udp: yes
do-tcp: yes
do-ip6: no
prefer-ip6: no
hide-identity: yes
hide-version: yes
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: no
edns-buffer-size: 1232
prefetch: yes
num-threads: 1
so-rcvbuf: 1m
private-address: <IP_ADDRESS>/16
private-address: <IP_ADDRESS>/16
private-address: <IP_ADDRESS>/12
private-address: <IP_ADDRESS>/8
private-address: fd00::/8
private-address: fe80::/10
If I remove the outgoing-interface line, unbound successfully communicates over enp0s3 through the default gateway (no VPN) and returns DNS results.
Also, if I allow the OpenVPN connection to modify the default gateway, unbound successfully communicates through the tunnel if outgoing-interface is set to the tunnel IP, or even if the outgoing-interface line is removed entirely. I have confirmed with DNS leak tests that in this configuration, the IP of the DNS server matches the VPN IP. When the default gateway is not modified by OpenVPN, even if outgoing-interface is set to the VPN tunnel IP, it fails.
I have tried various other suggestions I've found such as tcp-upstream: yes, but nothing makes any difference. I have also disabled ufw for this test.
System:
Ubuntu 22.04
Unbound setup:
Recursive DNS
No forwarders
Installed via apt.
unbound -V:
Version 1.13.1
Configure line: --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --disable-rpath --with-pidfile=/run/unbound.pid --with-rootkey-file=/var/lib/unbound/root.key --with-libevent --with-libnghttp2 --with-pythonmodule --enable-subnet --enable-dnstap --enable-systemd --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --libdir=/usr/lib
Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.2 15 Mar 2022
Linked modules: dns64 python subnetcache respip validator iterator

It is possible to set verbosity: 5 on unbound, and then look into the logs, the logfile can be set with logfile: /root/unbound.log for example, and that gives details as to what unbound does. It attempts to bind to the interface address and then send to the destination IP. The logs could show if there are errors printed out. Or if the traffic just disappears.

It is possible to set verbosity: 5 on unbound, and then look into the logs, the logfile can be set with logfile: /root/unbound.log for example, and that gives details as to what unbound does. It attempts to bind to the interface address and then send to the destination IP. The logs could show if there are errors printed out. Or if the traffic just disappears.

Thanks for the reply! I had done this before, but I was unable to determine anything useful from the log except that it is never getting a reply. I can't tell from the log, even at log level 5, what interface it is trying to use to send/listen. I don't see this information anywhere in the log.
I logged both with allowing OpenVPN to change the default gateway and without. In both cases, outgoing-interface is set to the VPN IP. In case 1 (default gateway changed to VPN IP address) it works and the log shows a response. In case 2 (default gateway left as-is), the log shows a timeout waiting for the response. I also cannot tell whether the traffic is reaching the destination.
Case 1 (default gateway changed to VPN IP address):
Feb 07 08:37:52 unbound[35006:0] info: sending query: . NS IN
Feb 07 08:37:52 unbound[35006:0] debug: sending to target: <.> <IP_ADDRESS>#53
Feb 07 08:37:52 unbound[35006:0] debug: dnssec status: expected
Feb 07 08:37:52 unbound[35006:0] debug: EDNS lookup known=0 vs=0
Feb 07 08:37:52 unbound[35006:0] debug: serviced query UDP timeout=376 msec
Feb 07 08:37:52 unbound[35006:0] debug: inserted new pending reply id=e05b
Feb 07 08:37:52 unbound[35006:0] debug: opened UDP if=0 port=48974
Feb 07 08:37:52 unbound[35006:0] debug: comm point start listening 14 (-1 msec)
Feb 07 08:37:52 unbound[35006:0] debug: mesh_run: iterator module exit state is module_wait_reply
Feb 07 08:37:52 unbound[35006:0] info: mesh_run: end 2 recursion states (1 with reply, 0 detached), 1 waiting replies, >
Feb 07 08:37:52 unbound[35006:0] info: 0pvCD mod2  . NS IN
Feb 07 08:37:52 unbound[35006:0] info: 1RDdc mod2 rep google.com. A IN
Feb 07 08:37:52 unbound[35006:0] debug: cache memory msg=66072 rrset=66072 infra=8105 val=66352 subnet=74504
Feb 07 08:37:52 unbound[35006:0] debug: answer cb
Feb 07 08:37:52 unbound[35006:0] debug: Incoming reply id = e05b
Feb 07 08:37:52 unbound[35006:0] debug: Incoming reply addr = ip4 <IP_ADDRESS> port 53 (len 16)
Feb 07 08:37:52 unbound[35006:0] debug: lookup size is 1 entries
Feb 07 08:37:52 unbound[35006:0] debug: received udp reply.
Case 2 (default gateway left as-is):
Feb 07 08:29:09 unbound[18597:0] info: sending query: . NS IN
Feb 07 08:29:09 unbound[18597:0] debug: sending to target: <.> <IP_ADDRESS>#53
Feb 07 08:29:09 unbound[18597:0] debug: dnssec status: expected
Feb 07 08:29:09 unbound[18597:0] debug: EDNS lookup known=0 vs=0
Feb 07 08:29:09 unbound[18597:0] debug: serviced query UDP timeout=376 msec
Feb 07 08:29:09 unbound[18597:0] debug: inserted new pending reply id=f0bc
Feb 07 08:29:09 unbound[18597:0] debug: opened UDP if=0 port=53890
Feb 07 08:29:09 unbound[18597:0] debug: comm point start listening 14 (-1 msec)
Feb 07 08:29:09 unbound[18597:0] debug: mesh_run: iterator module exit state is module_wait_reply
Feb 07 08:29:09 unbound[18597:0] info: mesh_run: end 2 recursion states (1 with reply, 0 detached), 1 waiting replies, >
Feb 07 08:29:09 unbound[18597:0] info: 0pvCD mod2  . NS IN
Feb 07 08:29:09 unbound[18597:0] info: 1RDdc mod2 rep dns.msftncsi.com. A IN
Feb 07 08:29:09 unbound[18597:0] debug: cache memory msg=66072 rrset=66072 infra=8105 val=66352 subnet=74504
Feb 07 08:29:10 unbound[18597:0] debug: timeout udp
Feb 07 08:29:10 unbound[18597:0] debug: try edns1xx0 <.> <IP_ADDRESS>#53
Feb 07 08:29:10 unbound[18597:0] debug: EDNS lookup known=0 vs=0
Feb 07 08:29:10 unbound[18597:0] debug: serviced query UDP timeout=376 msec
Feb 07 08:29:10 unbound[18597:0] debug: inserted new pending reply id=113b
Feb 07 08:29:10 unbound[18597:0] debug: opened UDP if=0 port=23013
Feb 07 08:29:10 unbound[18597:0] debug: comm point start listening 15 (-1 msec)
Feb 07 08:29:10 unbound[18597:0] debug: close of port 53890
Feb 07 08:29:10 unbound[18597:0] debug: comm_point_close of 14: event_del
Feb 07 08:29:10 unbound[18597:0] debug: close fd 14
Feb 07 08:29:10 unbound[18597:0] debug: timeout udp
Feb 07 08:29:10 unbound[18597:0] debug: svcd callbacks start
Feb 07 08:29:10 unbound[18597:0] debug: worker svcd callback for qstate 0x559de2145750
Feb 07 08:29:10 unbound[18597:0] debug: mesh_run: start
Feb 07 08:29:10 unbound[18597:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_norep>
Feb 07 08:29:10 unbound[18597:0] info: iterator operate: query . NS IN
Feb 07 08:29:10 unbound[18597:0] debug: process_response: new external response event
Feb 07 08:29:10 unbound[18597:0] debug: iter_handle processing q with state QUERY RESPONSE STATE
Feb 07 08:29:10 unbound[18597:0] debug: query response was timeout

The message opened UDP if=0 port=23013 relates to the outgoing interface, it picked if=0. That is the only one that is configured, the IP address of the outgoing-interface configuration. It logs the index in the interface table, inside unbound.
From the logs, the first works and the second has timeouts. Since unbound just binds to the IP that you specify, and then sends a UDP packet to the destination, there is little to see or fix, all unbound does is bind a the IP and send to the destination. Since there is a timeout, no reply returns. The system allows the send call to succeed, it does not give an error, and the system also allows to bind to the outgoing interface address. That does not mean the packet is actually sent, but to the unbound source code, or in its logs, it looks fine. And no reply returns. So that means the tunnel setup does not allow return packets in some way? If the tunnel setup would not send packets I guess there would be errors in the send call. With tcpdump on the tunnel it may be possible to see if packets leave or return? Or perhaps other stuff like the route table or firewall is blocking access to the tunnel. The default gateway setting is a route table setting, so I guess that something is wrong with the route table, perhaps there is some other gateway there that drops all traffic, that would otherwise be replaced by the vpn gateway?

Thanks for the insight! I've decided to solve the issue a different way using multiple VMs.

I guess the issue can be closed, then. There was something wrong with sending packets over the tunnel, but what is not sure.


fix: LSDV-5296: Disconnect observer

PR fulfills these requirements

[ ] Commit message(s) and PR title follows the format [fix|feat|ci|chore|doc]: TICKET-ID: Short description of change made ex. fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errors
[ ] Tests for the changes have been added/updated (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] Best efforts were made to ensure docs/code are concise and coherent (checked for spelling/grammatical errors, commented out code, debug logs etc.)
[ ] Self-reviewed and ran all changes on a local instance (for bug fixes/features)

Change has impacts in these area(s)
(check all that apply)

[ ] Product design
[ ] Frontend

Describe the reason for change
(link to issue, supportive screenshots etc.)
What does this fix?
(if this is a bug fix)
What is the new behavior?
(if this is a breaking or feature change)
What is the current behavior?
(if this is a breaking or feature change)
What libraries were added/updated?
(list all with version changes)
Does this change affect performance?
(if so describe the impacts positive or negative)
Does this change affect security?
(if so describe the impacts positive or negative)
What alternative approaches were there?
(briefly list any if applicable)
What feature flags were used to cover this change?
(briefly list any if applicable)
Does this PR introduce a breaking change?
(check only one)

[ ] Yes, and covered entirely by feature flag(s)
[ ] Yes, and covered partially by feature flag(s)
[ ] No
[ ] Not sure (briefly explain the situation below)

What level of testing was included in the change?
(check all that apply)

[ ] e2e
[ ] integration
[ ] unit

Which logical domain(s) does this change affect?
(for bug fixes/features, be as precise as possible. ex. Authentication, Annotation History, Review Stream etc.)

Codecov Report
Patch coverage: 100.00% and project coverage change: -1.55 :warning:

Comparison is base (c1f9712) 66.52% compared to head (119b2fd) 64.97%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1484      +/-   ##
==========================================
- Coverage   66.52%   64.97%   -1.55%
==========================================
  Files         439      439
  Lines       27462    27464       +2
  Branches     7283     7176     -107
==========================================
- Hits        18269    17846     -423
- Misses       7910     9618    +1708
+ Partials     1283        0    -1283

Impacted Files
Coverage Δ

src/tags/object/Paragraphs/HtxParagraphs.js
75.89% <100.00%> (+0.21%)
:arrow_up:

... and 217 files with indirect coverage changes

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


Default config file "CNN_RNN_CTC_BLS.json" not working during inference

InvalidArgumentError (see above for traceback): 0-th value returned by pyfunc_0 is int32, but expects int64          [[node model/PyFunc (defined at F:\Toys\Urdu OCR\Urdu-Handwriting-Recog nition-using-Deep-Learning-master\models\lm.py:150) ]]
I'm on windows and using a conda environment.
Seems like some issue with tensorflow's datatypes.
Also the gui does not work if the config file is changed. I fixed this by editing the "loading_complete" method in run_gui.py.
I can run the other configurations and the only difference in the configs is the "decoder-type: Prefix_beam_search" which I think is somehow linked with how you are using the language model.
Could you please also guide to some resource on how the language model is being integrated at the output of the model in your code.

The code for the language model follows more or less this: https://towardsdatascience.com/word-beam-search-a-ctc-decoding-algorithm-b051d28f3d2e
The main difference is that the algorithm in this article was specifically designed for English where a 'space' indicates the end of word, whereas in Urdu we have no spaces. Since the scheme that I used for transcription differentiated between whether a character was at the start, middle or end of a word, I simply changed the 'space' condition to an 'ending character' condition.
For the datatype error you're encountering, make sure that you're using the same versions of the library as mentioned in the requirements.txt file. Otherwise, as far as this error is concerned, if you explicitly cast the variables (indices, values, shape) being returned at line 145 in models/lm.py to np.int64, I think the error should go away.


Finish unwinding idempotent payload logic

The recent ROCm change partially removed idempotent payloads, but the ggml-metal.metal file for mac was still idempotent.  This finishes switching to always extract the payloads, and now that idempotentcy is gone, the version directory is no longer useful.
Tested on mac and linux.

Looks good. Would we have to worry about cleaning up old assets that are unused? (e.g. conflicting libraries)

Good point - let me refine a bit more so I can safely remove payload assets and not interfere with installer assets. (I'll add a subdir back for payloads just not versioned)


librosa caching

Probably we want to depend on librosa 0.4(-dev) and enable caching on a per-object basis.

The deformation script should reset cache after each track is processed

This is best done in the application script, not inside muda.


Gtoplist signs not updating past rank 14

Using paper 1.13.2 and jobs v4.13.1 I can't get my gtoplist signs to update past rank 14 and display as blank even though /jobs gtop shows rank 1-87. the individual toplist signs for each job works though it's just gtoplist past rank is the problem. Any ideas whats causing this?

paper 1.13.2
jobs v4.13.1
Also, I was curious if you knew about the issue with points connecting with bosshsoppro? Apparently something changed with how points work and no longer links to bossshoppro. The plugin is now mostly abandoned so I was wondering if jobs reborn is reverting back to the old ways or do I have to forever stay with jobs v4.12.0

The sign updates fixed in this commit.
For BossShopPro, the developer is not following the Jobs updates, so this is not Jobs problem.

Using jobs reborn v4.14.3 the signs still don't work. Doing
[jobs]
gtoplist
1
results in a blank sign. I also tried 1s. I verified I was in fact part of a job


Client: Reset context without closing and reconfiguring

When running a wakaama client on a connection which might be lost without warning, it is not possible to reset the lwm2m_context in preparation for connection reestablishment. If a connection is reestablished within re-transmission time there will still be items in the transactionList and these will interfere with the (re-)registration process.
Would a "lwm2m_reset" function be a suitable addition for this purpose? Pull request will be added

Just for information:
Leshan is able to "match" the client using the peer's "Principal".
That means: even if a new handshake is executed, the above layers are not affected by that new handshake, as long as the Principal (identity) stay the same. Some years ago, this was discussed over and over in the oma/lwm2m. On argument against that was RFC 7252 9.1.2. A discussion on the IETF core mailing list then shows, that this definition has some weakness.
So, I'm not that clear, what "will interfere".
Also, as least in the past, some DTLS libraries suppert a "DTLS role exchange" as well. That means, your client may not be even not aware, that there is a new DTLS session (at least not without listen to additional library events).

Based on current test, I agree with @pehrnord: it seems that Leshan is not handling propertly reconfiguration of observations after a client being impacted by a change in its IP address.
Let me add a log, comments:
- client is a wakaama interfacing with Leshan server
- I am adding only an "abstract" of client's log to make it easier to follow
- As a summary:
a) Battery /3/0/9 changes to 56 but fails to send notify because device is offline
b) As a result of above, device forces itself going online to send pending notification
c) Once online:  performs first a Register Update, then sends NOTIFY /3/0/9 to server
d) Server responds first with an ACK of Register Update and then...
e) Server responds with a RST to received notification. Under LwM2M, this means server is not recognizing received notification but requests client to stop retransmitting that notificacion
f) After above, client behaves ok as following /3/0/9 resource updates do not trigger any notification
...
         targetP: 0x4b8f80a0   uri:/3/0/9
                watcherP: 0x4b8f80c0    active: 1       update: 0
...
[engine]:       *** event battery changed to 56
...
         targetP: 0x4b8f80a0   uri:/3/0/9
                watcherP: 0x4b8f80c0    active: 1       update: 1
[engine]:       ERROR at sendto(), invalid socket: assuming we are OFFLINE...
[engine]:              failed sending 21 bytes to <IP_ADDRESS>:13078 [connP addr: 000001294b8f74f0]
[engine]:       *** Observed Failed ==> going offline?
...
[engine]:  <<< OFFLINE >>>  at<PHONE_NUMBER>
[engine]:       *** Trigered notification without conditions at /3/0/9
[engine]:       > pending notification, requesting going online
...
[engine]:  <<< ONLINE >>>  at<PHONE_NUMBER>
...
[>>]: 126 bytes sent to Server [sock = 320]     -->  REGISTER UPDATE
...
          targetP: 0x4b8f80a0   uri:/3/0/9
                watcherP: 0x4b8f80c0    active: 1       update: 1
...
[>>]: 21 bytes sent to Server [sock = 320]      -->  NOTIFY /3/0/9
      NON | 205 CONTENT       | | MsgID = 0x5c86 | Token = 0x8D6147F4F372681E | Content type = TLV |
      Request Type: DEVICE MNG     Uri: /65535/65535/65535
...
[<<]: 8 bytes received from [<IP_ADDRESS>]     -->  ACK REGISTER UPDATE
...
          targetP: 0x4b8f80a0   uri:/3/0/9
                watcherP: 0x4b8f80c0    active: 1       update: 0
...
[<<]: 4 bytes received from [<IP_ADDRESS>]     -->  acknoledge is a RST NOTIFY
      RST | 000 NO_ERROR       | | MsgID = 0x5c86 | Token = 0x | Content type = Text plain |
      Request Type: DEVICE MNG     Uri: /65535/65535/65535     No Payload
...
[engine]:       *** event battery changed to 27
...
[engine]:  <<< OFFLINE >>>  at<PHONE_NUMBER>
[engine]:  <<< OFFLINE >>>   113 secs to expire
[engine]:       *** event battery changed to 72
Summary:  Leshan seems not to reconfigure client context after an IP address client's update. Any previous notifications are not longer accepted by server.

FMPOV, an ip-capture will help much more ...
how to ip-capturing

@dbarallat did you test with or without DTLS ?


Use bootstrap ui plugin maybe?

Just wondering:
Couldnt https://github.com/backstageel/cakephp-gentelella-theme/blob/master/src/View/Helper/FormHelper.php be removed if one would just build on top of https://github.com/FriendsOfCake/bootstrap-ui plugin?
Because then you can use the full stack of bootstrap and you only need to put a few small CSS or classes on top of it :)

Thanks for the reference... I will test the Theme with Bootstrap UI Plugin and do the update.

Cool!
Once all is completed and you maybe have a few tests for the remaining classes you can also submit it to https://github.com/FriendsOfCake/awesome-cakephp#skeleton for everyone to more easily find :)


Change type of NewAssociatedDeal to match HubSpot field

Description
fixes serialization / deserialization issues with equipment object
Purpose

[ ] Bugfix - change type of NewAssociatedDeal to match HubSpot field (non-breaking change which fixes an issue)

Checklist

[ ] I have added tests to prove that what I have fixed or added does indeed work
[ ] I have added documentation as necessary

fixed by https://github.com/boomandbucket/HubSpot.NET/pull/13


Revert commits 1.3.0rc0

Reverting non_max_suppression_v2 op and @caisq tfdbg change for cloudml-gpu build.

The revert for non_max_suppression has more conflicts than expected. Pushing it back to rc1.

Jenkins, test this please.

http://ci.tensorflow.org/job/tensorflow-pull-requests-multijob/5894/


Give merchant information in backend if payment has not been captured yet

Add note to documentation regarding Klarnas approval for auto-capture.
https://pm.bitspire.de/issues/8599

Please review as discussed @josetonyp ;)


Devs SBAT to use SDK for all smart contract interactions

Expected Behavior
Devs SBAT to use SDK for all smart contract interactions
Current Behavior
Some interactions are hardcoded in mobile, some are hardcoded in the celotool, and some elsewhere.

Closing as dupe of smaller issues


Danfoss Ally radiator thermostat

Issue

I have connected a Danfoss Ally radiator thermostat.
I only thing I can see in my Homekit App  is current / desired temperature.
Is the Danfoss Ally radiator thermostat not fully integrated yet, as I'm getting the log messages below?
I have added the Danfoss Ally ZigBee Cluster Specification.
Log Messages

[19/11/2021, 06:33:57] [Hue] Phoscon-GW: request 16674: api error 6: parameter, mode, not available
[19/11/2021, 06:33:58] [Hue] Gæstetoilet: homekit target heating cooling state changed from 0 to 1
[19/11/2021, 06:33:58] [Hue] Phoscon-GW: request 16675: PUT /sensors/37/config {"mode":"auto"}
[19/11/2021, 06:33:58] [Hue] Phoscon-GW: request 16675: api error 6: parameter, mode, not available
[19/11/2021, 06:34:16] [Hue] Gæstetoilet: homekit target heating cooling state changed from 1 to 0
[19/11/2021, 06:34:16] [Hue] Phoscon-GW: request 16684: PUT /sensors/37/config {"mode":"off"}
[19/11/2021, 06:34:16] [Hue] Phoscon-GW: request 16684: api error 6: parameter, mode, not available
[19/11/2021, 06:34:18] [Hue] Gæstetoilet: homekit target heating cooling state changed from 0 to 1
[19/11/2021, 06:34:18] [Hue] Phoscon-GW: request 16685: PUT /sensors/37/config {"mode":"auto"}
[19/11/2021, 06:34:18] [Hue] Phoscon-GW: request 16685: api error 6: parameter, mode, not available
[19/11/2021, 06:34:20] [Hue] Gæstetoilet: homekit target heating cooling state changed from 1 to 0
[19/11/2021, 06:34:20] [Hue] Phoscon-GW: request 16688: PUT /sensors/37/config {"mode":"off"}
[19/11/2021, 06:34:20] [Hue] Phoscon-GW: request 16688: api error 6: parameter, mode, not available
[19/11/2021, 06:34:21] [Hue] Gæstetoilet: homekit target heating cooling state changed from 0 to 1
[19/11/2021, 06:34:21] [Hue] Phoscon-GW: request 16689: PUT /sensors/37/config {"mode":"auto"}
[19/11/2021, 06:34:21] [Hue] Phoscon-GW: request 16689: api error 6: parameter, mode, not available
[19/11/2021, 06:34:23] [Hue] Gæstetoilet: homekit target heating cooling state changed from 1 to 0
[19/11/2021, 06:34:23] [Hue] Phoscon-GW: request 16690: PUT /sensors/37/config {"mode":"off"}
[19/11/2021, 06:34:23] [Hue] Phoscon-GW: request 16690: api error 6: parameter, mode, not available
[19/11/2021, 06:34:30] [Hue] Gæstetoilet: homekit target heating cooling state changed from 0 to 1
[19/11/2021, 06:34:30] [Hue] Phoscon-GW: request 16695: PUT /sensors/37/config {"mode":"auto"}
[19/11/2021, 06:34:30] [Hue] Phoscon-GW: request 16695: api error 6: parameter, mode, not available
[19/11/2021, 06:34:31] [Hue] Gæstetoilet: homekit target heating cooling state changed from 1 to 0
[19/11/2021, 06:34:31] [Hue] Phoscon-GW: request 16696: PUT /sensors/37/config {"mode":"off"}
[19/11/2021, 06:34:31] [Hue] Phoscon-GW: request 16696: api error 6: parameter, mode, not available
Debug Files

Danfoss Ally ZigBee Cluster Specification - AM375549618098en-000101.pdf

If it’s not fully implemented in deCONZ, you need to open an issue there.  If it is, and your asking for Homebridge Hue support, I need the debug dump file to see how the API exposes the TRV.  I probably also need a description of what each API attribute does, as this tends to be different for different types of TRVs; the API is failing to standardise these.

See #1046: A ZHAThermostat resource without config.mode is simply incompatible with HomeKit.  I will issue a warning for these.  Other than not exposing the incompatible ZHAThermostat, there's nothing I can do here.  The thermostat needs to be exposed properly by deCONZ.


Reproduction

Thank you for this great research!
I'm working on a reproduction of thumos'14 dataset as you explained on github, but there are so different results, can you tell me what's wrong?

Could you share your training log? I cannot know the reason without any information but I guess the most possible reason is that you didn't load the pretrained checkpoint (Swin) properly.

Hi @klauscc, thanks for the fast reply.
Thank you for your answer!
I'm sorry I didn't give you any information when I asked you
Below is part of the training record you requested from me.
Thank you
2023-05-04 15:53:08,932 - vedatad - WARNING - EvalHook is not in modes ['train']
2023-05-04 15:53:08,933 - vedatad - INFO - Loading weights from ./TALLFormer/data/pretrained_models/vswin/swin_base_patch244_window877_kinetics400_22k.pth
2023-05-04 15:53:37,654 - vedatad - INFO - Epoch [1][10/200] lr: 0.001162, loss_cls: 0.0106, loss_segment: 0.0000, loss: 0.0106. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:54:03,246 - vedatad - INFO - Epoch [1][20/200] lr: 0.001342, loss_cls: 1.0979, loss_segment: 0.4382, loss: 1.5361. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:54:27,018 - vedatad - INFO - Epoch [1][30/200] lr: 0.001522, loss_cls: 0.0129, loss_segment: 0.0000, loss: 0.0129. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:54:51,051 - vedatad - INFO - Epoch [1][40/200] lr: 0.001702, loss_cls: 1.1229, loss_segment: 0.4017, loss: 1.5246. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:55:16,249 - vedatad - INFO - Epoch [1][50/200] lr: 0.001882, loss_cls: 0.0170, loss_segment: 0.0000, loss: 0.0170. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:55:38,502 - vedatad - INFO - Epoch [1][60/200] lr: 0.002062, loss_cls: 1.1106, loss_segment: 0.3743, loss: 1.4849. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:56:05,632 - vedatad - INFO - Epoch [1][70/200] lr: 0.002242, loss_cls: 0.0226, loss_segment: 0.0000, loss: 0.0226. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:56:28,797 - vedatad - INFO - Epoch [1][80/200] lr: 0.002422, loss_cls: 0.0274, loss_segment: 0.0000, loss: 0.0274. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:56:52,678 - vedatad - INFO - Epoch [1][90/200] lr: 0.002602, loss_cls: 0.9924, loss_segment: 0.4774, loss: 1.4698. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:57:16,824 - vedatad - INFO - Epoch [1][100/200] lr: 0.002782, loss_cls: 0.0437, loss_segment: 0.0000, loss: 0.0437. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:57:44,137 - vedatad - INFO - Epoch [1][110/200] lr: 0.002962, loss_cls: 0.9717, loss_segment: 0.7659, loss: 1.7376. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:58:08,570 - vedatad - INFO - Epoch [1][120/200] lr: 0.003142, loss_cls: 0.8817, loss_segment: 0.5009, loss: 1.3826. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:58:33,239 - vedatad - INFO - Epoch [1][130/200] lr: 0.003322, loss_cls: 0.7935, loss_segment: 0.4218, loss: 1.2152. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:58:59,090 - vedatad - INFO - Epoch [1][140/200] lr: 0.003502, loss_cls: 0.9445, loss_segment: 0.5547, loss: 1.4991. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:59:24,424 - vedatad - INFO - Epoch [1][150/200] lr: 0.003682, loss_cls: 0.1632, loss_segment: 0.0000, loss: 0.1632. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 15:59:45,005 - vedatad - INFO - Epoch [1][160/200] lr: 0.003862, loss_cls: 0.1635, loss_segment: 0.0000, loss: 0.1635. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:00:10,690 - vedatad - INFO - Epoch [1][170/200] lr: 0.004042, loss_cls: 0.8258, loss_segment: 0.4272, loss: 1.2530. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:00:35,373 - vedatad - INFO - Epoch [1][180/200] lr: 0.004222, loss_cls: 0.8884, loss_segment: 0.4481, loss: 1.3365. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:01:01,577 - vedatad - INFO - Epoch [1][190/200] lr: 0.004402, loss_cls: 0.2212, loss_segment: 0.0000, loss: 0.2212. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:01:26,497 - vedatad - INFO - Epoch [1][200/200] lr: 0.004582, loss_cls: 0.8863, loss_segment: 0.5291, loss: 1.4154. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:01:57,215 - vedatad - INFO - Epoch [2][10/200] lr: 0.004761, loss_cls: 0.1545, loss_segment: 0.0000, loss: 0.1545. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:02:21,210 - vedatad - INFO - Epoch [2][20/200] lr: 0.004941, loss_cls: 0.1363, loss_segment: 0.0000, loss: 0.1363. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:02:46,275 - vedatad - INFO - Epoch [2][30/200] lr: 0.005121, loss_cls: 0.9597, loss_segment: 0.6925, loss: 1.6522. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:03:12,107 - vedatad - INFO - Epoch [2][40/200] lr: 0.005301, loss_cls: 0.8522, loss_segment: 0.4234, loss: 1.2756. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:03:38,483 - vedatad - INFO - Epoch [2][50/200] lr: 0.005481, loss_cls: 0.8081, loss_segment: 0.4241, loss: 1.2322. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:04:03,662 - vedatad - INFO - Epoch [2][60/200] lr: 0.005661, loss_cls: 0.7717, loss_segment: 0.5368, loss: 1.3085. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:04:30,991 - vedatad - INFO - Epoch [2][70/200] lr: 0.005841, loss_cls: 0.2303, loss_segment: 0.0000, loss: 0.2303. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:04:56,341 - vedatad - INFO - Epoch [2][80/200] lr: 0.006021, loss_cls: 0.8816, loss_segment: 0.4065, loss: 1.2881. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:05:20,894 - vedatad - INFO - Epoch [2][90/200] lr: 0.0062, loss_cls: 0.8249, loss_segment: 0.3766, loss: 1.2015. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:05:50,024 - vedatad - INFO - Epoch [2][100/200] lr: 0.00638, loss_cls: 0.9783, loss_segment: 0.3360, loss: 1.3143. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:06:17,077 - vedatad - INFO - Epoch [2][110/200] lr: 0.00656, loss_cls: 0.2497, loss_segment: 0.0000, loss: 0.2497. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:06:40,218 - vedatad - INFO - Epoch [2][120/200] lr: 0.00674, loss_cls: 0.9363, loss_segment: 0.2470, loss: 1.1833. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:07:02,719 - vedatad - INFO - Epoch [2][130/200] lr: 0.00692, loss_cls: 0.8670, loss_segment: 0.2904, loss: 1.1574. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:07:25,481 - vedatad - INFO - Epoch [2][140/200] lr: 0.0071, loss_cls: 0.8623, loss_segment: 0.3295, loss: 1.1918. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:07:51,522 - vedatad - INFO - Epoch [2][150/200] lr: 0.00728, loss_cls: 0.8167, loss_segment: 0.4119, loss: 1.2286. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:08:16,953 - vedatad - INFO - Epoch [2][160/200] lr: 0.00746, loss_cls: 0.8758, loss_segment: 0.3163, loss: 1.1921. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:08:42,429 - vedatad - INFO - Epoch [2][170/200] lr: 0.00764, loss_cls: 1.0376, loss_segment: 0.3804, loss: 1.4180. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:09:08,421 - vedatad - INFO - Epoch [2][180/200] lr: 0.00782, loss_cls: 0.9150, loss_segment: 0.3612, loss: 1.2762. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:09:32,581 - vedatad - INFO - Epoch [2][190/200] lr: 0.008, loss_cls: 0.9645, loss_segment: 0.3181, loss: 1.2826. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:09:58,296 - vedatad - INFO - Epoch [2][200/200] lr: 0.00818, loss_cls: 0.9310, loss_segment: 0.5488, loss: 1.4797. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:10:23,891 - vedatad - INFO - Epoch [3][10/200] lr: 0.008354, loss_cls: 0.8809, loss_segment: 0.3079, loss: 1.1887. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:10:49,706 - vedatad - INFO - Epoch [3][20/200] lr: 0.008534, loss_cls: 0.9389, loss_segment: 0.2615, loss: 1.2005. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:11:15,864 - vedatad - INFO - Epoch [3][30/200] lr: 0.008713, loss_cls: 0.2471, loss_segment: 0.0000, loss: 0.2471. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:11:42,715 - vedatad - INFO - Epoch [3][40/200] lr: 0.008893, loss_cls: 0.9052, loss_segment: 0.5896, loss: 1.4948. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:12:08,863 - vedatad - INFO - Epoch [3][50/200] lr: 0.009073, loss_cls: 0.8455, loss_segment: 0.3013, loss: 1.1468. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:12:31,386 - vedatad - INFO - Epoch [3][60/200] lr: 0.009253, loss_cls: 0.9299, loss_segment: 0.2641, loss: 1.1940. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:12:57,274 - vedatad - INFO - Epoch [3][70/200] lr: 0.009433, loss_cls: 0.9760, loss_segment: 0.2667, loss: 1.2427. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:13:22,554 - vedatad - INFO - Epoch [3][80/200] lr: 0.009613, loss_cls: 0.8918, loss_segment: 0.6661, loss: 1.5579. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:13:47,474 - vedatad - INFO - Epoch [3][90/200] lr: 0.009792, loss_cls: 0.2193, loss_segment: 0.0000, loss: 0.2193. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:14:13,101 - vedatad - INFO - Epoch [3][100/200] lr: 0.009972, loss_cls: 0.8596, loss_segment: 0.4270, loss: 1.2865. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:14:38,801 - vedatad - INFO - Epoch [3][110/200] lr: 0.00999, loss_cls: 0.2437, loss_segment: 0.0000, loss: 0.2437. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:15:02,495 - vedatad - INFO - Epoch [3][120/200] lr: 0.00999, loss_cls: 0.9165, loss_segment: 0.2800, loss: 1.1966. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:15:28,737 - vedatad - INFO - Epoch [3][130/200] lr: 0.00999, loss_cls: 0.9726, loss_segment: 0.5439, loss: 1.5166. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:15:55,543 - vedatad - INFO - Epoch [3][140/200] lr: 0.00999, loss_cls: 0.7967, loss_segment: 0.4046, loss: 1.2013. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:16:20,935 - vedatad - INFO - Epoch [3][150/200] lr: 0.00999, loss_cls: 0.6963, loss_segment: 0.3128, loss: 1.0091. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:16:47,426 - vedatad - INFO - Epoch [3][160/200] lr: 0.00999, loss_cls: 1.1223, loss_segment: 0.3358, loss: 1.4581. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:17:13,177 - vedatad - INFO - Epoch [3][170/200] lr: 0.00999, loss_cls: 0.2135, loss_segment: 0.0000, loss: 0.2135. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:17:39,261 - vedatad - INFO - Epoch [3][180/200] lr: 0.00999, loss_cls: 0.1977, loss_segment: 0.0000, loss: 0.1977. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:18:06,327 - vedatad - INFO - Epoch [3][190/200] lr: 0.00999, loss_cls: 0.2039, loss_segment: 0.0000, loss: 0.2039. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:18:29,601 - vedatad - INFO - Epoch [3][200/200] lr: 0.00999, loss_cls: 0.2540, loss_segment: 0.0000, loss: 0.2540. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:18:57,516 - vedatad - INFO - Epoch [4][10/200] lr: 0.009978, loss_cls: 0.2088, loss_segment: 0.0000, loss: 0.2088. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:19:22,700 - vedatad - INFO - Epoch [4][20/200] lr: 0.009978, loss_cls: 0.6433, loss_segment: 0.2874, loss: 0.9307. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:19:47,285 - vedatad - INFO - Epoch [4][30/200] lr: 0.009978, loss_cls: 0.8336, loss_segment: 0.3942, loss: 1.2278. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:20:11,655 - vedatad - INFO - Epoch [4][40/200] lr: 0.009978, loss_cls: 0.8414, loss_segment: 0.7160, loss: 1.5574. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:20:36,791 - vedatad - INFO - Epoch [4][50/200] lr: 0.009978, loss_cls: 0.8508, loss_segment: 0.3303, loss: 1.1812. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:21:04,146 - vedatad - INFO - Epoch [4][60/200] lr: 0.009978, loss_cls: 0.8807, loss_segment: 0.2536, loss: 1.1343. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:21:27,378 - vedatad - INFO - Epoch [4][70/200] lr: 0.009978, loss_cls: 0.7235, loss_segment: 0.2419, loss: 0.9654. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:21:58,680 - vedatad - INFO - Epoch [4][80/200] lr: 0.009978, loss_cls: 0.8348, loss_segment: 0.2509, loss: 1.0857. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:22:23,894 - vedatad - INFO - Epoch [4][90/200] lr: 0.009978, loss_cls: 0.3101, loss_segment: 0.0000, loss: 0.3101. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:22:50,949 - vedatad - INFO - Epoch [4][100/200] lr: 0.009978, loss_cls: 0.6917, loss_segment: 0.3080, loss: 0.9997. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:23:14,172 - vedatad - INFO - Epoch [4][110/200] lr: 0.009978, loss_cls: 0.9035, loss_segment: 0.2530, loss: 1.1564. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:23:39,402 - vedatad - INFO - Epoch [4][120/200] lr: 0.009978, loss_cls: 0.8982, loss_segment: 0.3027, loss: 1.2009. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:24:03,675 - vedatad - INFO - Epoch [4][130/200] lr: 0.009978, loss_cls: 0.7626, loss_segment: 0.3293, loss: 1.0919. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:24:28,834 - vedatad - INFO - Epoch [4][140/200] lr: 0.009978, loss_cls: 0.8966, loss_segment: 0.3007, loss: 1.1973. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:24:56,292 - vedatad - INFO - Epoch [4][150/200] lr: 0.009978, loss_cls: 0.9530, loss_segment: 0.3195, loss: 1.2725. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:25:21,071 - vedatad - INFO - Epoch [4][160/200] lr: 0.009978, loss_cls: 0.8266, loss_segment: 0.2984, loss: 1.1250. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:25:48,876 - vedatad - INFO - Epoch [4][170/200] lr: 0.009978, loss_cls: 0.8867, loss_segment: 0.3635, loss: 1.2502. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:26:18,835 - vedatad - INFO - Epoch [4][180/200] lr: 0.009978, loss_cls: 0.7449, loss_segment: 0.2955, loss: 1.0404. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:26:46,456 - vedatad - INFO - Epoch [4][190/200] lr: 0.009978, loss_cls: 0.2784, loss_segment: 0.0000, loss: 0.2784. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:27:11,197 - vedatad - INFO - Epoch [4][200/200] lr: 0.009978, loss_cls: 0.6941, loss_segment: 0.2766, loss: 0.9706. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:27:39,669 - vedatad - INFO - Epoch [5][10/200] lr: 0.009961, loss_cls: 0.7778, loss_segment: 1.0342, loss: 1.8120. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:28:05,426 - vedatad - INFO - Epoch [5][20/200] lr: 0.009961, loss_cls: 0.2894, loss_segment: 0.0000, loss: 0.2894. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:28:34,510 - vedatad - INFO - Epoch [5][30/200] lr: 0.009961, loss_cls: 0.9554, loss_segment: 0.7894, loss: 1.7448. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:28:58,697 - vedatad - INFO - Epoch [5][40/200] lr: 0.009961, loss_cls: 0.8909, loss_segment: 0.7336, loss: 1.6245. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:29:24,849 - vedatad - INFO - Epoch [5][50/200] lr: 0.009961, loss_cls: 0.9242, loss_segment: 0.2747, loss: 1.1989. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:29:50,931 - vedatad - INFO - Epoch [5][60/200] lr: 0.009961, loss_cls: 0.7743, loss_segment: 0.2718, loss: 1.0461. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:30:18,840 - vedatad - INFO - Epoch [5][70/200] lr: 0.009961, loss_cls: 0.2002, loss_segment: 0.0000, loss: 0.2002. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:30:43,641 - vedatad - INFO - Epoch [5][80/200] lr: 0.009961, loss_cls: 0.9389, loss_segment: 0.4348, loss: 1.3736. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:31:12,624 - vedatad - INFO - Epoch [5][90/200] lr: 0.009961, loss_cls: 0.7192, loss_segment: 0.2735, loss: 0.9927. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:31:39,963 - vedatad - INFO - Epoch [5][100/200] lr: 0.009961, loss_cls: 0.8517, loss_segment: 0.3424, loss: 1.1940. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:32:07,302 - vedatad - INFO - Epoch [5][110/200] lr: 0.009961, loss_cls: 0.7893, loss_segment: 0.2926, loss: 1.0818. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:32:36,106 - vedatad - INFO - Epoch [5][120/200] lr: 0.009961, loss_cls: 0.7977, loss_segment: 0.2876, loss: 1.0854. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:33:04,567 - vedatad - INFO - Epoch [5][130/200] lr: 0.009961, loss_cls: 0.2253, loss_segment: 0.0000, loss: 0.2253. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:33:27,371 - vedatad - INFO - Epoch [5][140/200] lr: 0.009961, loss_cls: 0.7584, loss_segment: 0.8574, loss: 1.6158. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:33:54,173 - vedatad - INFO - Epoch [5][150/200] lr: 0.009961, loss_cls: 0.8726, loss_segment: 0.2155, loss: 1.0881. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:34:18,031 - vedatad - INFO - Epoch [5][160/200] lr: 0.009961, loss_cls: 0.3459, loss_segment: 0.0000, loss: 0.3459. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:34:46,711 - vedatad - INFO - Epoch [5][170/200] lr: 0.009961, loss_cls: 0.2037, loss_segment: 0.0000, loss: 0.2037. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:35:14,553 - vedatad - INFO - Epoch [5][180/200] lr: 0.009961, loss_cls: 0.8858, loss_segment: 0.4636, loss: 1.3494. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:35:39,227 - vedatad - INFO - Epoch [5][190/200] lr: 0.009961, loss_cls: 1.0109, loss_segment: 0.4460, loss: 1.4568. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:36:07,258 - vedatad - INFO - Epoch [5][200/200] lr: 0.009961, loss_cls: 0.8053, loss_segment: 0.3468, loss: 1.1521. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:36:36,568 - vedatad - INFO - Epoch [6][10/200] lr: 0.009939, loss_cls: 0.6395, loss_segment: 0.7749, loss: 1.4144. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:37:03,396 - vedatad - INFO - Epoch [6][20/200] lr: 0.009939, loss_cls: 0.8347, loss_segment: 0.3463, loss: 1.1810. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:37:31,062 - vedatad - INFO - Epoch [6][30/200] lr: 0.009939, loss_cls: 0.8433, loss_segment: 0.2666, loss: 1.1099. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:37:56,005 - vedatad - INFO - Epoch [6][40/200] lr: 0.009939, loss_cls: 0.5777, loss_segment: 0.3121, loss: 0.8898. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:38:24,828 - vedatad - INFO - Epoch [6][50/200] lr: 0.009939, loss_cls: 0.6238, loss_segment: 1.4121, loss: 2.0358. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:38:49,137 - vedatad - INFO - Epoch [6][60/200] lr: 0.009939, loss_cls: 0.8003, loss_segment: 0.3907, loss: 1.1910. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:39:20,971 - vedatad - INFO - Epoch [6][70/200] lr: 0.009939, loss_cls: 0.7334, loss_segment: 0.3959, loss: 1.1293. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB
2023-05-04 16:39:46,748 - vedatad - INFO - Epoch [6][80/200] lr: 0.009939, loss_cls: 0.8980, loss_segment: 0.3540, loss: 1.2521. max mem allocated: 3944.36865234375 MB. max reservered: 4468.0 MB

Hi @klauscc, thanks for the fast reply.
Thank you for your answer!
I'm sorry I didn't provide any information when I asked you
Below is part of the training record you requested from me.
Thank you