Constant Desync/Stuttering Issues During Gameplay

Video constantly desyncs from song audio during low impact play on sub-10 difficulty charts. Not to mention it also stutters more than an autistic child with a lisp.
Also multiple game crashes caused by sound reader when using OGG files. mp3 just floats away as i play.

Can I have some good examples of files with this issue?

Literally anything from SMO that isnt pre-parsed by your environment.

Gonna need some specific examples.

I'm not sure what you mean by pre-parsed. The most we've done is delete bloated stuff from packs, and that concerns EO itself, not Etterna. This is a game issue. I need specific examples.

ECS7 Qualifiers pack, Propane Nightmares [15], after the first run, the game stutters, then desyncs by 30ms. It happens any time there is a VPF spike in engine.

There is no 7 on SMO?

http://groovestats.com/ECS7/download/ECS7.zip

That file isn't under 10....
Also I don't want to play 10 minutes of something, do you have an example from a relevant pack?

Relevant to spread players? Nope. But this issue exists for anyone trying to run etterna on a pad level use.

Nobody was giving you shit, but uh. A file from another pack would be useful, basically one that isn't going to require me to play for 10 minutes to test.
Also you stated it was files under 10, but provided a 16 - I don't mind that level, but yea.

The issue also occurs in Jayce's "Feel The Notes" pack. I've had the same issue with every chart in that pack.

OK, I've managed to reproduce this. I don't know how, but we can look into this - thanks for bringing it to our attention.

It's a legitimate issue. I didn't manage to reproduce, but I'll look into it.

I can't find "Feel The Note" on https://search.stepmaniaonline.net/

Alright. Good luck fam. Closing issue now that it's known.

did you expect us to intentionally not fix something despite being provided the issue, source and examples?
we'd have to be stepmania to do that
opening until a commit solves it

Yeah, I gotta agree with you there. Neither of us are Stepmania. You guys are Project Etterna, we're Team Rizu. So that I can agree on :P

If you have any other input on this issue, I{d apprecciate it. Thanks for the report.

If I find anything, I'll let you guys know. Our code differences are pretty wide now, so pinpointing the issue in the code here might take longer than expected.

ok im having trouble reproducing this so can i get some info
any hardware info you think is relevant?
os?
vsync? if not whats your general gameplay fps?
release build or develop?
ssd or hdd for songs folder?

It might be useful to know if the stutter also happens on previews, or just gameplay

The stutter happens with vsync off, release install client, SSD install, all settings default except visual delay at +25ms. Running in OpenGL mode.
Drive load spikes are noticed when in song wheel. Same behavior causing the issue in gameplay, resulting in desync.

Are you on linux?

Win10 x64

100%  have this issue watch  any YT recording of the game you will see the stutter prefs watch etiennes  channel and it should become obvious

Uh, that's a different issue from the one brought up here. Etienne and others suffer from the microstutters that most players get, we're also looking into that however this issue was for a very specific stutter bug.

Did some forensic work here and found something kind of interesting.
The .sms of the Feel The Notes pack have the line #TICKCOUNT:0.000=2; present in nearly all of the charts.
Since I haven't ever seen that property before, I looked through my entire song library (which is decently large; 5731 songs), and only found 3 other instances of that field in any of them outside of that pack.
Given how rare this attribute is, and the fact that every chart in Feel The Notes had it, I have to wonder if it's potentially related.
It's also entirely possible that this is a red herring and has absolutely nothing to do with the issue.
However, Propane Nightmares from ECS Qualifiers does not have this attribute set, so that can't solely be the cause of this issue, if it is the cause for Feel The Notes.
The other three songs from my collection that contain this attribute are below, in case we want to do further investigation as to whether they do or don't also have the aforementioned stutters.
/Songs/midare megapack 4/(HST) HST's OP -penance-/hst.sm:#TICKCOUNT:0.000=2;
/Songs/the Leftovers 3/minefield surfing  (Windoze)/[Speed Changes] - minefield surfing.sm:#TICKCOUNT:0.000=2;
/Songs/FFR Community Pack Novice Files Compilation/Poseidon (Kors K Mix) (Gameoson)/poseidon.sm:#TICKCOUNTS:0.000=2

In Gameplay, tickcount is fully irrelevant in the current game and the issue persists. Tickcount code still exists in gameplay but is never executed because we hardcoded it to be disabled for every style and every game.

the issue being described has been unable to be replicated by anyone looking at the issue or any general player in the last 4.5 years so
user error is going to be assumed


[bootstrap-vcpkg.sh] restore removed eval call

As suggested in https://github.com/microsoft/vcpkg/issues/37035#issuecomment-1969389886
cc @SchaichAlonso
Fixes #37035
Fixes #37045

LGTM (I'm not authoritative though)

Giving this a second, what's the point of using a cmake arguments variable (with or without nested quotes) here in the first place?
I'm not a ninja expert, so if I want concurrent compilation, I pass --parallel to cmake --build rather then manually setting up a job pool, and --parallel has always worked for me so far. In fact it also works w/o Ninja, e.g. with Unix Makefiles or msbuild, while the job pool stuff is ninja specific.
If the job pool stuff doesn't do anything that --parallel doesn't, then the code block handling the cmake arguments and cmake invokations, namely
cmakeConfigOptions="-DCMAKE_BUILD_TYPE=Release -G 'Ninja' -DVCPKG_DEVELOPMENT_WARNINGS=OFF"

if [ "${VCPKG_MAX_CONCURRENCY}" != "" ] ; then
        cmakeConfigOptions=" $cmakeConfigOptions '-DCMAKE_JOB_POOL_COMPILE:STRING=compile' '-DCMAKE_JOB_POOL_LINK:STRING=link' '-DCMAKE_JOB_POOLS:STRING=compile=$VCPKG_MAX_CONCURRENCY;link=$VCPKG_MAX_CONCURRENCY' "
fi

(cd "$buildDir" && eval cmake "$srcDir" $cmakeConfigOptions) || exit 1
(cd "$buildDir" && cmake --build .) || exit 1

could be
(cd "$buildDir" && eval cmake "$srcDir" -DCMAKE_BUILD_TYPE=Release -G Ninja -DVCPKG_DEVELOPMENT_WARNINGS=OFF) || exit 1
(cd "$buildDir" && cmake --build . --parallel ${VCPKG_MAX_CONCURRENCY:-1}) || exit 1

where the eval statement is redundand because there's no nested quotes any more.
Further, cmake 3.13 and newer have -S and -B arguments to specify the source and the build directories, allowing to invoke cmake outside of the build directory
(eval cmake -B "$buildDir" -S "$srcDir" -DCMAKE_BUILD_TYPE=Release -G Ninja -DVCPKG_DEVELOPMENT_WARNINGS=OFF) || exit 1
(cmake --build "$buildDir" --parallel ${VCPKG_MAX_CONCURRENCY:-1}) || exit 1

Without the cd statements we can then drop the brackets, and reorder the cmake arguments to not interleave the generator into varriable definitions, to get
eval cmake -B "$buildDir" -S "$srcDir" -G Ninja -DCMAKE_BUILD_TYPE=Release -DVCPKG_DEVELOPMENT_WARNINGS=OFF || exit 1
cmake --build "$buildDir" --parallel ${VCPKG_MAX_CONCURRENCY:-1} || exit 1

A preset defining CMAKE_BUILD_TYPE, VCPKG_DEVELOPMENT_WARNINGS, generator and buildDir can further clean this up. Preset Files are JSON, so we don't have to bother about whitespace escaping madness if the generator ever becomes "Ninja Multi-Config". vcpkg-tool already has a preset file, it just doesn't contain a preset storing the constants passed to the only cmake invokation that the boostrap-vcpkg script ever performs.
In case the job pool stuff doesn't do just simply the same thing --parallel does... then we can configure all the job pool variables in a preset, in addition to the non-ninja-specific variables, and branch between the job pool preset and the basic preset in the shell script, instead of appending cmake args.
Getting the Prefix into vcpkg-tool will take it's time though, so ahead with this PR.

@SchaichAlonso comments aside, I'm taking this PR since it quickly fixes an issue right now.


"force" param for asset generator

I want to use the asset generator during a step in my bitrise workflow. Are there any plans to add something like a "--force" or "--overwrite" parameter to have the generator finish without asking permission?

Just came with the same problem and solved it using yeoman generator --force command.
yo rn-toolbox:assets  --icon icon.png --projectName yourProject --force


stm32u5xx_hal_dma_ex.c doesn't build with arm-none-eabi-gcc

Caution
This issue is not on your file but on the compiler.
However it has impact on your customers and it's in your interest to make ARM/GCC fix the issue. This issue can at least serve as notice of heads-up for next people that will encounter the problem.
Describe the set-up

arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi.zip from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads will segfault on compilation of stm32u5xx_hal_dma_ex.c with -O3

Describe the bug (skip if none)
Compiler segfault
How to reproduce the bug (skip if none)

Downloaded arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi.zip from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
In attached zip, modify and run compilerBug.bat (will just compile 1 faulty file known to work)
observe segmentation fault in compiler

minimalInc.zip
Additional context
I have already reported bug on Linaro: https://bugs.linaro.org/show_bug.cgi?id=5924
Screenshots
C:\FW>"C:\GIT\FW_Toolchain\GNU Tools ARM Embedded\12.2.rel1\bin\arm-none-eabi-gcc.exe" -DSTM32U575xx=1 -IC:/FW/minimalInc -O3 -DNDEBUG -freport-bug -mcpu=cortex-m33 -mthumb -mfpu=fpv5-sp-d16 -mfloat-abi=hard --specs=nano.specs -ffunction-sections -fdata-sections -fno-builtin -Wall -Wfatal-errors -O3 -std=gnu17 -o stm32u5xx_hal_dma_ex.c.obj -c C:/FW/minimalInc/stm32u5xx_hal_dma_ex.c
during GIMPLE pass: evrp
C:/FW/minimalInc/stm32u5xx_hal_dma_ex.c: In function 'HAL_DMAEx_List_ReplaceNode_Head':
C:/FW/minimalInc/stm32u5xx_hal_dma_ex.c:4689:1: internal compiler error: Segmentation fault
 4689 | }
      | ^
Please submit a full bug report, with preprocessed source.
See <https://bugs.linaro.org/> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

Note the build also fails with GCC 11.3.1 from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

Hello @atsju,
Thank you for your contribution. As you said, this issue is not related to our drivers and we do not address this aspect in our GitHub repositories. We are happy that the issue has been resolved. Thanks again for your report. We look forward to hearing from you again.
Please allow me to close the issue.
With Regards,


.ino is main file extension for arduino files

Interesting, does Prism do aliases like this?

Interesting, does Prism do aliases like this?

I looked at the python language and that's how they handled py and python

Ruby also. Prism.languages.rb = Prism.languages.ruby;
Perhaps you are right. :)  Just wasn't aware of this.

Thank you for contributing @Outreach-ChemEng-UofU!


fix: Add sort_key and sort_order to table search

Since the table search currently doesn't have a sort order, this PR is to have the search result list in ascending order using schema and name.

That's sounds reasonable, we were thinking of adding this eventually as well.
So the sorting would be Ascending/Descending vs Importance Score?

@czgu Added the changes for the UI as suggested and found out that the importance_score sorting wasn't working correctly on the schema table sort so made a small change to fix it. Let me know if this is good


Improve stacker error message - Detect if stacker is already running and using the same cache

If stacker dies because another instance is already running (using the same cache), please mention so in the error message; optionally, also try to find the other stacker PID and log it.

Do you have an example of stacker dying because of this?


Compute node OOM for nexmark queries with nightly-20240108

Describe the bug
We have a lot of OOM for the daily nexmark performance test pipelines with nightly-20240108.
https://buildkite.com/risingwave-test/nexmark-benchmark/builds/2827
https://buildkite.com/risingwave-test/nexmark-benchmark/builds/2828
https://buildkite.com/risingwave-test/nexmark-benchmark/builds/2829
The memory usage are all like this build https://buildkite.com/risingwave-test/nexmark-benchmark/builds/2827

Error message/log
No response
To Reproduce
No response
Expected behavior
No response
How did you deploy RisingWave?
No response
The version of RisingWave
nightly-20240108
Additional context
The new commits in nightly-20240108 https://github.com/risingwavelabs/rw-commits-history?tab=readme-ov-file#nightly-20240108

The same OOM issue occurred longevity test pipeline.
https://buildkite.com/risingwave-test/longevity-test/builds/894
https://buildkite.com/risingwave-test/longevity-test/builds/895

This can be caused by https://github.com/risingwavelabs/risingwave/pull/14375#discussion_r1444167523 (This is resolved by #14427) + #14220

1704728569-2024-01-08-15-42-48.auto.heap.collapsed.zip

#14375 cherry-picked into release-1.6, should we cherry-pick #14427 and #14220 into release-1.6?

No OOM for nightly-20240109 daily performance test. So close this one.


How to create devices

In the Create a provisioning profile section under Next, select the devices to use for testing, and select Continue. what if there is no device created?

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

ID: 6f96a6e9-8b01-fe0b-c6ec-2afd2c69a5e8
Version Independent ID: cfda931c-cac9-8d25-d20c-7b3308e9eeed
Content: Send push notifications to iOS using Azure Notification Hubs and the iOS SDK
Content Source: articles/notification-hubs/ios-sdk-get-started.md
Service: notification-hubs
GitHub Login: @sethmanheim
Microsoft Alias: sethm

@ljunquera, I have assigned the issue to the content author to investigate further and update the document as appropriate.

@ljunquera Thank you for reaching out and very sorry for the slow response. Please open a support ticket for further help with this issue. #please-close


handle newline problems.

My initial newlines caused problems so I withdrew them. Turns out pasted ones do too. They leave a very limited error message in the LAS log.

fixed in commit https://github.com/Brown-University-Library/easyscan/commit/a8112ae468b2e4d03fd02157c854a589d7f6dfde.


Update electrum to 2.6

Thank you for the contribution. It was merged directly as 962ad4a6a66798ac5c47b0d932b612fb5c2ba346 to keep commit history cleaner. Your contribution is still credited to you.


Introducing types and freeze functionality

Pull Request Test Coverage Report for Build 181

579 of 613 (94.45%)  changed or added relevant lines in 7 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-4.5%) to 95.042%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

omegaconf/listconfig.py
104
107
97.2%

omegaconf/dictconfig.py
75
80
93.75%

omegaconf/nodes.py
70
79
88.61%

omegaconf/config.py
316
333
94.89%

Totals

Change from base Build 175:
-4.5%

Covered Lines:
671

Relevant Lines:
706

💛  - Coveralls


nydus-snapshotter should look for nydusd/nydus-image in $PATH

Instead of hardcoding it or just relying on a fixed parameter.

Can I take this issue if it is not assigned yet?

Sure. Welcome to contribute.


Configure Netlify to only build docs on release

We don't want to ship docs to production that aren't included in an official release yet. The GH/Netlify shouldn't watch/build master directly; it should only trigger a build of the docs for new releases (tags).
There may be a way to configure Netlify settings to do this through our Netlify account/project settings UI. If not, we'll need custom code a solution to either trigger a Netlify build directly on new releases or detect when there's no new release in our tooling and bail accordingly.

Based on conversation with @philmprice, it sounds like the simplest option is to base the Netlify site on a docs branch that only gets updated whenever there's a release. A GH Actions setup or similar could fast-forward the docs branch automatically whenever a new release is created.


Min/Max color temperature has no effect

ColorTempPhysicalMaxMireds and ColorTempPhysicalMinMireds attributes are not affecting color temperature calculating, and also, parameters colorTemperatureMaximum and colorTemperatureMinimum of command StepColorTemperature and MoveColorTemperature are not affecting, too.
I found lowLimit and highLimit of struct type Color16uTransitionState are set but never used in color-control-server.cpp, SDK commit is: 903e149bd636a5cd1a8821864cb073b4f7a9d3d8 of TE4.
How to reproduce:
chip-device-ctrl > zclread ColorControl ColorTemperature 12344321 1 0
attributeValue: 250

chip-device-ctrl > zcl ColorControl StepColorTemperature 12344321 1 0 stepMode=1 stepSize=10 transitionTime=300 colorTemperatureMinimum=5 colorTemperatureMaximum=250 optionsMask=0 optionsOverride=0

chip-device-ctrl > zclread ColorControl ColorTemperature 12344321 1 0
attributeValue: 260

@jmartinez-silabs

We're in progress of reviewing older issues. Is this still an issue given how old the SDK this was tested against? Please re-open if so. Thanks!


JobPayLoad doesn't supports misc

The JobPayLoad class doen'st supports the misc swaggerType. This is required for the webhooks to work.

will take a look soon


BUG: Arrows gone in mixed norm plotting

Glyph in glass brain in :
https://mne.tools/dev/auto_examples/inverse/plot_time_frequency_mixed_norm_inverse.html#sphx-glr-auto-examples-inverse-plot-time-frequency-mixed-norm-inverse-py
do not show up. I should see 2 sources.
Originally posted by @agramfort in https://github.com/mne-tools/mne-python/pull/8188#issuecomment-685065216

This has been incorrect going back to 0.18:
https://mne.tools/0.18/auto_examples/inverse/plot_time_frequency_mixed_norm_inverse.html#sphx-glr-auto-examples-inverse-plot-time-frequency-mixed-norm-inverse-py

It was broken by 78561338b1ffe376455e8a1324f55e2833979ce1, I'll try to figure out what the problem is...

:'(


[Enhancement]: Aligning the name of the application and toggle bar in same height

Is your enhancement request related to a problem? Please describe.➕

The name and the toggle bar is not at the same height and that doesnot look good so I would like to do a change.
Describe the solution you'd like
Solution steps
Include both the name and the toggle bar in the same div and applying the flex.
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @anilkoduru !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hey @anilkoduru ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Is there any way to close an outline row by default?

hello
I create outline rows like this
let row = worksheet.addRow(["data1",""data2"]);
row.outlineLevel = 1
That's code creates an outline group but the group is opened by default.
When I used vba I used to use code to close all groups like this
ActiveSheet.Outline.ShowLevels RowLevels:=1, ColumnLevels:=1
Is there any way to close an outline row by default?
thanks

I found the solution.
if you want to collapse a group just set row.hidden = true


WIP overlay: add custom /etc/nsswitch.conf

systemd-resolved seems to break mDNS plugin used in oVirt/vSphere installs.
Instead of

hosts:      files resolve [!UNAVAIL=return] myhostname dns

we should be using

hosts: files dns myhostname

(as in F32).
Ref: https://github.com/openshift/okd/issues/401

We should note that this is a workaround. Ideally this'll be fixed in the packages themselves

/retest
/test e2e-vsphere

/retest

/test e2e-vsphere

/retest

vSphere is still failing for unknown reason.
/skip
/retest

/cherrypick release-4.6


Add a system property to avoid the Signal handler registration

If the FlightRecorder is used and started it triggers the decomission
process if the USR2 signal handler is registered.
This adds a switch to prevent that. Since this is only intended for devs
this is an undocumented system property instead of a regular setting.

Codecov Report

Merging #6477 into master will decrease coverage by 0.02%.
The diff coverage is 50%.

@@             Coverage Diff              @@
##             master    #6477      +/-   ##
============================================
- Coverage        83%   82.97%   -0.03%
+ Complexity    13077    13072       -5
============================================
  Files          1499     1499
  Lines         48590    48591       +1
  Branches       5870     5871       +1
============================================
- Hits          40330    40320      -10
- Misses         5492     5495       +3
- Partials       2768     2776       +8

Impacted Files
Coverage Δ
Complexity Δ

...e/cluster/gracefulstop/DecommissioningService.java
51.88% <50%> (-0.5%)
15 <0> (ø)

...in/java/io/crate/lucene/match/CrateRegexQuery.java
47.82% <0%> (-34.79%)
5% <0%> (-4%)

...ration/reference/doc/lucene/IpColumnReference.java
72.72% <0%> (-13.64%)
5% <0%> (ø)

...crate/executor/transport/TransportShardAction.java
73.68% <0%> (-13.16%)
8% <0%> (-1%)

...io/crate/protocols/postgres/types/VarCharType.java
87.5% <0%> (-12.5%)
9% <0%> (-2%)

...ore/src/main/java/io/crate/types/GeoPointType.java
72.72% <0%> (-6.07%)
22% <0%> (-2%)

.../java/io/crate/blob/TransportDeleteBlobAction.java
75% <0%> (-5%)
4% <0%> (-1%)

...on/projectors/sharding/ShardingUpsertExecutor.java
89.02% <0%> (-4.88%)
16% <0%> (ø)

...e/operation/reference/sys/shard/SysAllocation.java
81.35% <0%> (-3.39%)
15% <0%> (-1%)

...in/java/io/crate/breaker/RamAccountingContext.java
81.66% <0%> (-3.34%)
20% <0%> (-2%)

... and 26 more

Continue to review full report at Codecov.

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


fix: image branch name

Co-Authored-By: Leonardo Di Donato<EMAIL_ADDRESS>Signed-off-by: Lorenzo Fontana<EMAIL_ADDRESS>What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area build
What this PR does / why we need it:
Fixes the GIT_BRANCH variable
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
NONE

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign leodido
You can assign the PR to them by writing /assign @leodido in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 4f7928ab7c5ed17484d4330c9299b8302efd2af1

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fntlnz
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [fntlnz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


stages: remove redundant entries of devices/mounts in schemas

With PR#1727 merged devices are now automatically added to all
stage schemas. This makes the existing schema entries of the form:
...
    },
    "devices": {
      "type": "object",
      "additionalProperties": true
    },
    "mounts": {
      "type": "array"
    }
...

redundant. This commit removes them. There are still some left
that are more specific (e.g. for filesystems) than this generic
one.
Note that mounts was already part of the stages schema automatically
since https://github.com/osbuild/osbuild/pull/847 (2021).

It also removes the stage specific tests for checking that our required bootc devices/mounts get accepted by the schema and moves that into the test/mod as it's now a generic module functionality.

Is there any harm in leaving them? I think having them as documentation of what is allowed is valuable.

Sure, that works for me (I have no super strong opinion either way), I removed this part of the PR. I still think there is value to have the test that checks that stages accept mounts/devices so I kept that but removed the other part that removed the definitions (cc @ondrejbudai too).


Fix duplicate metadata descriptions - 2

Ripple 3 validation cleanup for duplicate metadata descriptions and duplicate H1s.

Docs Build status updates of commit ad463a5:
:warning: Validation status: warnings

File
Status
Preview URL
Details

biztalk/core/how-to-add-a-message-for-an-exception1.md
:warning:Warning
View
Details

biztalk/core/how-to-add-a-message-for-an-exception2.md
:warning:Warning
View
Details

biztalk/adapters-and-accelerators/accelerator-hl7/how-biztalk-server-solves-the-business-need2.md
:white_check_mark:Succeeded
View

biztalk/adapters-and-accelerators/accelerator-hl7/known-issues1.md
:white_check_mark:Succeeded
View

biztalk/adapters-and-accelerators/accelerator-rosettanet/how-biztalk-server-solves-the-business-need1.md
:white_check_mark:Succeeded
View

biztalk/adapters-and-accelerators/accelerator-swift/known-issues5.md
:white_check_mark:Succeeded
View

biztalk/core/best-practices-for-managing-certificates1.md
:white_check_mark:Succeeded
View

biztalk/core/getcontextproperty1.md
:white_check_mark:Succeeded
View

biztalk/core/getcontextproperty2.md
:white_check_mark:Succeeded
View

biztalk/core/handling-string-values1.md
:white_check_mark:Succeeded
View

biztalk/core/handling-string-values2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block3.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block4.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block5.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block6.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-fault-message1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-fault-message2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-message-for-an-exception3.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape3.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape4.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape5.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-assign-message-context-property-values1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-assign-message-context-property-values2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-avoid-disk-contention1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-configure-the-http-receive-adapter1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-configure-the-http-receive-adapter2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-create-a-send-port1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-create-a-send-port2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-identify-bottlenecks-in-the-messagebox-database2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-analysis-database2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-archive-database2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-notification-services-databases2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-primary-import-database1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-star-schema-database1.md
:white_check_mark:Succeeded
View

biztalk/core/importing-schemas-into-biztalk-server-projects1.md
:white_check_mark:Succeeded
View

biztalk/core/importing-schemas-into-biztalk-server-projects2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/best-practices-for-managing-certificates2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-avoid-disk-contention2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-identify-bottlenecks-in-the-messagebox-database1.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-analysis-database1.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-archive-database1.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-notification-services-databases1.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-primary-import-database2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-star-schema-database2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/known-issues2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/low-latency-scenario-optimizations1.md
:white_check_mark:Succeeded
View

This comment lists only the first 50 files in the pull request.

biztalk/core/how-to-add-a-message-for-an-exception1.md

Line 22, Column 1: [Warning-duplicate-h1s] H1 'Add a Message for an Exception' is duplicated with other articles: 'core/how-to-add-a-message-for-an-exception1.md(22,1), core/how-to-add-a-message-for-an-exception2.md(23,1)'. First level headings must be unique within a docset.

biztalk/core/how-to-add-a-message-for-an-exception2.md

Line 23, Column 1: [Warning-duplicate-h1s] H1 'Add a Message for an Exception' is duplicated with other articles: 'core/how-to-add-a-message-for-an-exception1.md(22,1), core/how-to-add-a-message-for-an-exception2.md(23,1)'. First level headings must be unique within a docset.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
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.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
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 e7407aa:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/adapters-and-accelerators/accelerator-hl7/how-biztalk-server-solves-the-business-need2.md
:white_check_mark:Succeeded
View

biztalk/adapters-and-accelerators/accelerator-hl7/known-issues1.md
:white_check_mark:Succeeded
View

biztalk/adapters-and-accelerators/accelerator-rosettanet/how-biztalk-server-solves-the-business-need1.md
:white_check_mark:Succeeded
View

biztalk/adapters-and-accelerators/accelerator-swift/known-issues5.md
:white_check_mark:Succeeded
View

biztalk/core/best-practices-for-managing-certificates1.md
:white_check_mark:Succeeded
View

biztalk/core/getcontextproperty1.md
:white_check_mark:Succeeded
View

biztalk/core/getcontextproperty2.md
:white_check_mark:Succeeded
View

biztalk/core/handling-string-values1.md
:white_check_mark:Succeeded
View

biztalk/core/handling-string-values2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block3.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block4.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block5.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-catch-exception-block6.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-fault-message1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-fault-message2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-message-for-an-exception1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-message-for-an-exception2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-message-for-an-exception3.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape3.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape4.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-add-a-scope-shape5.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-assign-message-context-property-values1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-assign-message-context-property-values2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-avoid-disk-contention1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-configure-the-http-receive-adapter1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-configure-the-http-receive-adapter2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-create-a-send-port1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-create-a-send-port2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-identify-bottlenecks-in-the-messagebox-database2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-analysis-database2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-archive-database2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-notification-services-databases2.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-primary-import-database1.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-move-the-bam-star-schema-database1.md
:white_check_mark:Succeeded
View

biztalk/core/importing-schemas-into-biztalk-server-projects1.md
:white_check_mark:Succeeded
View

biztalk/core/importing-schemas-into-biztalk-server-projects2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/best-practices-for-managing-certificates2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-avoid-disk-contention2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-identify-bottlenecks-in-the-messagebox-database1.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-analysis-database1.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-archive-database1.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-notification-services-databases1.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-primary-import-database2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/how-to-move-the-bam-star-schema-database2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/known-issues2.md
:white_check_mark:Succeeded
View

biztalk/technical-guides/low-latency-scenario-optimizations1.md
:white_check_mark:Succeeded
View

This comment lists only the first 50 files in the pull request.
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

@MandiOhlinger More validation fixes ready for your review. Thanks!


In electron-vue, display doesn't work

Found an issue or bug with electron-vue? Tell me all about it!
Questions regarding how to use electron or vue are likely to be closed as they are not direct issues with this boilerplate. Please seek solutions from official documentation or their respective communities.
Describe the issue / bug.
#
I use Bulma, and when I go on a page with a specific template, it's stuck at where I arrived and I can't scroll. If I refresh by pressing F5, all works fine.
How can I reproduce this problem?
#
Use a bulma template from https://dansup.github.io/bulma-templates/ and choose the Kanban one, or the tabs one.
If visual, provide a screenshot.
#
https://nsa40.casimages.com/img/2019/02/10/190210110553586689.png
Tell me about your development environment.

Node version:latest
NPM version:latest
vue-cli version: (if necessary)
Operating System: Windows 10

If you are looking to suggest an enhancement or feature, then feel free to remove everything above.

Hi, issue solved, it was a problem from vue which kept attributes from a page to an other, and as the scrollbar was hidden from a page it kept it for the other.


Fix some typos in the modeling doc chapter

Fixed minor typos in the Modeling chapter of the documentation.

Thanks João !
This is much appreciated. We still haven't set up the mechanism for accepting external PRs (we'll have that very soon), but I've fixed these typos internally. You will see these changes included in the next release.
Thanks again!


raftstore-v2: add snapshot basic logic in peer storage

Signed-off-by: nolouch<EMAIL_ADDRESS>
What is changed and how it works?

Issue Number: Ref https://github.com/tikv/tikv/issues/12842
What's Changed:
Part of https://github.com/tikv/tikv/pull/13439

this commit is part of support snapshot in raftstore v2
- add snapshot basic implementation in peer storage

Related changes

PR to update pingcap/docs/pingcap/docs-cn:
Need to cherry-pick to the release branch

Check List
Tests

Unit test

Release note
None

I suggest to handling applying snapshot in async writer and generating snapshot in raft log fetch worker.

I think putting the tasks in a work more readable currently and there is a destroy task need to maintain. maybe we can consider unifying some works later.

I think putting the tasks in a work more readable currently and there is a destroy task need to maintain. maybe we can consider unifying some works later.

Destroying a peer is just a simple write in async writer. Applying snapshot is also a simple write in async writer, what else needs to be done is renaming the directory.

Moved generate to log fetch worker

/test

/test

PTAL @BusyJay @tonyxuqqi

/test

/test

PTAL @BusyJay @Connor1996

Now generating and applying snapshot become very lightweight, I suggest to handling applying snapshot in async writer and generating snapshot in raft log fetch worker.

@BusyJay  @nolouch raft log fetch worker may accumulate lots of tasks, it's unwise to generate snapshot there.

@BusyJay @nolouch raft log fetch worker may accumulate lots of tasks, it's unwise to generate snapshot there.

Then we should use a thread pool for the read tasks.

@BusyJay @nolouch raft log fetch worker may accumulate lots of tasks, it's unwise to generate snapshot there.

Then we should use a thread pool for the read tasks.

Fetch log tasks can still exhaust the threads, and affect snapshot generation. Better not to mix it with heavy io tasks.

Fetch log tasks can still exhaust the threads, and affect snapshot generation. Better not to mix it with heavy io tasks.

It's not an ideal way to create a thread(pool) for every type of tasks. Fairness between tasks should be solved by the thread pool itself.

But for the blocking IO, it must suffer from blocking by fetch log tasks.

This is also doable. For example, using yatp for read tasks and change the fetch log tasks to execution slices. And v2 snapshot can be assigned with high priority. It's just the same as coprocessor.

Why bother to move it out from the region worker?

To reduce threads and unify concepts.

But for the blocking IO, it must suffer from blocking by fetch log tasks.

This is also doable. For example, using yatp for read tasks and change the fetch log tasks to execution slices. And v2 snapshot can be assigned with high priority. It's just the same as coprocessor.

Why bother to move it out from the region worker?

To reduce threads and unify concepts.

It may cost several hundred milliseconds, even seconds for one fetch log task. You can't keep the execution slice small.

It may cost several hundred milliseconds, even seconds for one fetch log task. You can't keep the execution slice small based on current raft engine implementation.

It's an IO operation for both snapshot and log fetches, seconds delay is OK. In practice, log fetch is unlikely to happen and seconds delay is even unlikely to happen.

It may cost several hundred milliseconds, even seconds for one fetch log task. You can't keep the execution slice small based on current raft engine implementation.

It's an IO operation for both snapshot and log fetches, seconds delay is OK. In practice, log fetch is unlikely to happen and seconds delay is even unlikely to happen.

But once it happens, a lot of tasks are triggered from different tasks. The number of pending tasks may keep at a high level for a while. And we currently have the mechanism to prefill cache before transfer-leader, it's likely to happen often.

But once it happens, a lot of tasks are triggered from different tasks. The number of pending tasks may keep at a high level for a while. And we currently have the mechanism to prefill cache before transfer-leader, it's likely to happen often.

Let's find out whether seconds delay really matters in real world tests after all are implemented. It's always an easy job to offload the snapshot to a dedicate thread if necessary.

But once it happens, a lot of tasks are triggered from different tasks. The number of pending tasks may keep at a high level for a while. And we currently have the mechanism to prefill cache before transfer-leader, it's likely to happen often.

Let's find out whether seconds delay really matters in real world tests after all are implemented. It's always an easy job to offload the snapshot to a dedicate thread if necessary.

Then use yatp and assign the task high priority, otherwise the delay is minutes rather seconds.

@Connor1996  I will try to replace it with yatp later. ptal current part.

/merge

/test

/test


Getting the css class name binding to play nice with others

Fixed the css mixin to work with other classNameBindings

[x] #patch# - backwards-compatible bug fix
[ ] #minor# - adding functionality in a backwards-compatible manner
[ ] #major# - incompatible API change

CHANGELOG

Fixed the css mixin to work with other classNameBindings

:+1:

Agreed to leave special component properties (classNames, classNameBindings, etc.) out of getDefaultProps


More refactoring

@amj
Separate out train.py; refactor --model_dir vs --working_dir; combine export_model/freeze_graph

Oh, also - I don't intend to merge any of the refactor PRs until it's all done. I've split out the multiple changes into different PRs so that they can be reviewed in increments.


Remove all feature use, enabling stable rust

rust-fuse running with stable rustc.. awesome work! Let's update dependency versions and release 0.2.7?

I see you updated the dependencies already.  Yes, I think a new release is warranted. :)


Add CANdy-Test genesis files

Signed-off-by: Wade Barnes<EMAIL_ADDRESS>

@PhilippeBourque, Thanks for the review.  Updates made.

Weird.  It should merge automatically if you approve the PR in the review changes section, but it looks like you've already approved it.  Perhaps try again.

It's look like I'm not autorize to Write on this repo.

It looks like we'll need @swcurran or @watkinspd to approve the PR for it to be merged.


dep: Upgrade the telemetry packages

Fixes a few security issues

@opentelemetry/api: 1.0.1 => 1.9.0
@opentelemetry/core: 0.23.0 => 1.25.1
@opentelemetry/exporter-collector-grpc is replaced with @opentelemetry/exporter-trace-otlp-grpc (see https://www.npmjs.com/package/@opentelemetry/exporter-trace-otlp-grpc)
@opentelemetry/instrumentation: 0.23.0 => 0.52.1
@opentelemetry/instrumentation-express: 0.23.0 => 0.40.1
@opentelemetry/instrumentation-http: 0.23.0 => 0.52.1
@opentelemetry/resources: 0.23.0 => 1.25.1
@opentelemetry/node is replaced with @opentelemetry/sdk-trace-node (see https://www.npmjs.com/package/@opentelemetry/sdk-trace-node)
@opentelemetry/tracing is replaced with @opentelemetry/sdk/trace/base (see https://www.npmjs.com/package/@opentelemetry/sdk-trace-base)

@greenscientist there is nothing in the code base that uses opentelemetry, so I can't make any of the required changes. The infra may need to be updated, with the changes of packages

Yeah, there's some impact. Discussing offline.

The docker build failure seems related to their side, I don't see any error in the log, it just seem to get stuck installing some package.


docs: add and improve documentation

What this PR changes/adds
Adds and updates documentation about the FederatedCatalog, its architecture and APIs
Why it does that
Briefly state why the change was necessary.
Further notes
List other areas of code that have changed but are not necessarily linked to the main feature. This could be method
signature changes, package declarations, bugs that were encountered and were fixed inline, etc.
Linked Issue(s)
Closes #197
Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 73.30%. Comparing base (2d71ca0) to head (b09d355).
Report is 45 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #200      +/-   ##
==========================================
+ Coverage   65.43%   73.30%   +7.86%
==========================================
  Files          25       20       -5
  Lines         434      427       -7
  Branches       15       22       +7
==========================================
+ Hits          284      313      +29
+ Misses        135       97      -38
- Partials       15       17       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[ci][docker] fix the path of custom toolchain in ci_qemu for csinn2

fix the path of custom toolchain in ci_qemu for csinn2
cc @areusch  @Mousius @driazati

hi @areusch, the nightly rebuild has passed with the PR of support CSI-NN2.  but before docker image is pushed from tlcpackstaging to tlcpack, I hope to fix this bug. I don't know if there is something wrong with my process? What do you think?

@alter-xp my apologies, we were out for a week and i didn't see this beforehand. are we good to build/push new ci_qemu images now?
as an aside--there's been discussion on #11809 about building purpose-driven images, so just as a heads-up we may be renaming ci_qemu to be microTVM-specific and splitting the CSI-NN2 qemu into its own image. this shouldn't impact your work--we'll just move the test invocations when we do.

thanks @areusch.  I will continue to add the following things once the nightly rebuild has passed with this PR.


Submodules

What is This Mess?
This was a rather large endeavor and admittedly my commit history is a little messy... here's a summary of the changes I made:

I added the concept of "packages" to the organization of GMF modules. This requires that modules in the same package specify which package they are in:
{
	"name": "A GMF Module",
	"package": "package_name",
	"remarks": [],
	"states": {}
}

The package should match the name of the directory that is used to organize the modules/submodules. Submodules may only be used within their package. Two examples of packages can be found in the fixtures/ folder. For example, the test_package is organized as:
test_package/
  test_package.json
  submodule.json

The file for the main module in the package must match the name of the package directory. That's how we know it's the main module.

I added a CallSubmodule state that may be used to invoke execution of a submodule. For example, a CallSubmodule state may look like:
"Pregnancy_Labs": {
	"type": "CallSubmodule",
	"submodule": "Pregnancy Labs Submodule",
	"args": {
	  "encounter": "12_Week_Visit"
	},
	"direct_transition": "15_Week_Visit"
}

When first processed, a CallSubmodule state does the following:

Initializes a new Synthea::Generic::Context for the submodule.
Passes the current history of the parent module to the submodule's context.
Passes any arguments to the submodule's context (more on arguments later).
Begins executing the submodule from it's Initial state in the same time step as the parent module.
Records the CallSubmodule state's exit time as the current time and adds the CallSubmodule state to the history.

If and when a submodule returns (by reaching a Terminal state), the parent module then processes the CallSubmodule state a second time. This does the following:

Copies the up-to-date history of the submodule back to its parent module.
Records the Terminal state in the history.
Continues execution of the parent module in the same time step as the submodule.

I added the concept of passing "arguments" to submodules. To keep submodules and parent modules loosely coupled, parent modules may pass key:value pairs of strings to a submodule as "arguments", similar to the way arguments are passed to a function call. An argument may be used to satisfy a reason, target_encounter, medication_order, condition_onset, or careplan property in a submodule that needs to reference a state in the parent module's history.
For example, if a submodule performs an observation that should be recorded at the same time as an encounter in the parent module, the parent module may pass the name of that Encounter state to the submodule:
"Pregnancy_Labs": {
	"type": "CallSubmodule",
	"submodule": "Pregnancy Labs Submodule",
	"args": {
	  "encounter": "12_Week_Visit"
	},
	"direct_transition": "15_Week_Visit"
}

And the submodule may then use it:
"Blood_Test_Result": {
	"type": "Observation",
	"target_encounter": "{encounter}",
	"codes": [],
	"direct_transition": "Next_State"
}

Arguments must start and end with curly braces { } and at present may only be strings. Arguments may be passed several levels deep in the context stack. For example, an argument may be passed from one submodule to another:
"Call_Submodule_From_Submodule": {
	"type": "CallSubmodule",
	"submodule": "Nested Submodule",
	"args": {
		"encounter": "{encounter}"
	},
	"direct_transition": "Submodule_Terminal_State"
}

At runtime the argument is evaulated and its value is obtained from the submodule's context.

I added support for displaying a CallSubmodule state in graphviz. To avoid confusion and conflicts with the dot syntax (where curly braces have special meaning), a CallSubmodule state and its arguments (if any) are displayed as follows:

Graphviz output is now organized by package. When a graphviz is generated for a package, each module/submodule is generated as a separate image file. All of these generated images are placed in a single folder that matches the name of the package.

I created a new ContextRunner object that manages a context stack. Each time a CallSubmodule state is reached a new context is pushed onto the stack. When a submodule returns (by reaching a Terminal state), its context is popped from the stack. During each time step, the ContextRunner simply executes whatever context is on the top of the stack. An empty stack means the module or package is finished for the current entity.

I moved logging responsibilities from Context to ContextRunner. The most up-to-date history in a package is always in the context at the top of the stack. This history may be a composition of the history from several different contexts that are each partially executed. Therefore a single context cannot be responsible for logging the history of the entire package.

Unit tests galore. I added comprehensive tests for each of the new items above.

Why Bother With All of This?
Our GMF modules are growing increasingly complex and becoming less DRY. The use of submodules is intended to introduce some DRY-ness and organization into the GMF. My "Top 3" existing areas that I think will benefit from submodules:

Repeating the Same Sequence of States. In the near future we need to add labs to the pregnancy module. These are the same or similar labs, performed at each visit to an OBGYN, 20-30 times during the course of a pregnancy. The only thing that varies each time is the target encounter that the labs are performed at. This screams DRY!

Complex Prescriptions. What medications are available in the current year of the simulation? What doses should be used for adults? Children? What alternative drugs can be prescribed if the patient has a drug allergy? This complexity can be expressed in the GMF but will require dozens of states that realistically do not belong in the main flow of the module.

Massive Modules. Think injuries. While the overall incidence of injuries can be handled by a single parent module, each injury could be placed in its own submodule. That way we could have a collection of 10-20 injury-specific submodules in a larger injuries package. Easier to read, easier to build, easier to maintain.

Any Limitations?
Validation. Currently we validate modules on an individual basis. Since packages span across several modules, and may pass key pieces of context using arguments, it is impossible to statically validate each module in a package by itself. We'll need to beef up the validation framework to validate packages.
Added complexity. There is a fair amount of overhead that goes into managing multiple contexts and calls to submodules. This makes it a little harder for others to implement GMF interpreters, but not by much. Hopefully Jeff doesn't mind.

I'm definitely in favor of the concept of submodules but I'm not sure about this implementation. My biggest concern is the additional complexity this adds to running modules. Context is already the most complicated class and this adds another level on top of that.
The concept of passing arguments is interesting, but it feels too limited in what it can do.  Take a look at the Allergies module: #120   The main core of the module is 3 states repeated 7 times with different values. With a more powerful system this could be represented a submodule of those 3 different states, and the different codes and percentages passed in as parameters. But I realize something like that can get too complex for people to read and follow so I guess there are tradeoffs.
The use of curly brackets around the name of an argument feels like a hack instead of using more traditional OO methods. Maybe this isn't the will of the team but I'm in favor of being more strict and explicit in the models rather than having 1 field be potentially multiple things which all have to be checked at runtime. Instead of "reason" : "xyz" where xyz could be a state name, attribute, or argument,  I'd much rather see "reason" : { "state" : "xyz" } or "reason" : { "attribute" : "xyz" } or "reason" : { "argument" : "xyz" } . The author has to know which one it is when they write it, why not save some processing time, both for the software itself and for later readers when they try to figure out what they're looking at?

+1 I think the concept is very useful and I’m experimenting with an implementation. The idea of passing (binding) states from a parent module into a subModule makes sense to me, and Codes would be useful too. The curly brackets mechanism for denoting an argument is ok with me until we gain more experience with subModules. Its nice to be OO but Ruby’s ability to dynamically add fields&methods to objects makes my static Java world a little more challenging.
I’ll add more thoughts as I wade into this a bit more.
Jeff

On Dec 29, 2016, at 8:47 AM, dehall<EMAIL_ADDRESS>wrote:
I'm definitely in favor of the concept of submodules but I'm not sure about this implementation. My biggest concern is the additional complexity this adds to running modules. Context is already the most complicated class and this adds another level on top of that.
The concept of passing arguments is interesting, but it feels too limited in what it can do. Take a look at the Allergies module: #120 https://github.com/synthetichealth/synthea/pull/120 The main core of the module is 3 states repeated 7 times with different values. With a more powerful system this could be represented a submodule of those 3 different states, and the different codes and percentages passed in as parameters. But I realize something like that can get too complex for people to read and follow so I guess there are tradeoffs.
The use of curly brackets around the name of an argument feels like a hack instead of using more traditional OO methods. Maybe this isn't the will of the team but I'm in favor of being more strict and explicit in the models rather than having 1 field be potentially multiple things which all have to be checked at runtime. Instead of "reason" : "xyz" where xyz could be a state name, attribute, or argument, I'd much rather see "reason" : { "state" : "xyz" } or "reason" : { "attribute" : "xyz" } or "reason" : { "argument" : "xyz" } . The author has to know which one it is when they write it, why not save some processing time, both for the software itself and for later readers when they try to figure out what they're looking at?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/synthetichealth/synthea/pull/121#issuecomment-269632285, or mute the thread https://github.com/notifications/unsubscribe-auth/AIO2lIvrhSMjFf6d1T8SCToOZ9sVz4c4ks5rM7oDgaJpZM4LWgP6.

I think its working for this limited test case. In this test, the first Encounter has the ConditionOnset and the MedicationOrder. From the trace, you can see that the subModule waits for the next wellness encounter (patient age = 0 so its not long). Context isn’t too hairy in my implementation as I’m just cloning the modules.
Need more test data!
Jeff
0 TestPerson [0] Initial [Initial]
2016/12/29 11:50 TestPerson [0] Encounter [Encounter]
1 TestPerson [0] Encounter [Encounter]
TestEncounterEvent [name=Encounter]
2017/01/05 10:50 TestPerson [0] Examplitis [ConditionOnset]
2017/01/05 10:50 TestPerson [0] CallSubmodule [CallSubroutine]
2 TestPerson [0] Initial [Initial]
2017/01/05 10:50 TestPerson [0] MedicationOrder [MedicationOrder]
TestMedication [name=MedicationOrder]
2017/01/05 11:50 TestPerson [0] Wellness [Encounter]
3 TestPerson [0] Wellness [Encounter]
2017/01/28 20:50 TestPerson [0] Sub_Terminal [Terminal]
2017/01/28 20:50 TestPerson [0] Main_Terminal [Terminal]

On Dec 29, 2016, at 10:14 AM, Jeastman<EMAIL_ADDRESS>wrote:
+1 I think the concept is very useful and I’m experimenting with an implementation. The idea of passing (binding) states from a parent module into a subModule makes sense to me, and Codes would be useful too. The curly brackets mechanism for denoting an argument is ok with me until we gain more experience with subModules. Its nice to be OO but Ruby’s ability to dynamically add fields&methods to objects makes my static Java world a little more challenging.
I’ll add more thoughts as I wade into this a bit more.
Jeff

On Dec 29, 2016, at 8:47 AM, dehall<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I'm definitely in favor of the concept of submodules but I'm not sure about this implementation. My biggest concern is the additional complexity this adds to running modules. Context is already the most complicated class and this adds another level on top of that.
The concept of passing arguments is interesting, but it feels too limited in what it can do. Take a look at the Allergies module: #120 https://github.com/synthetichealth/synthea/pull/120 The main core of the module is 3 states repeated 7 times with different values. With a more powerful system this could be represented a submodule of those 3 different states, and the different codes and percentages passed in as parameters. But I realize something like that can get too complex for people to read and follow so I guess there are tradeoffs.
The use of curly brackets around the name of an argument feels like a hack instead of using more traditional OO methods. Maybe this isn't the will of the team but I'm in favor of being more strict and explicit in the models rather than having 1 field be potentially multiple things which all have to be checked at runtime. Instead of "reason" : "xyz" where xyz could be a state name, attribute, or argument, I'd much rather see "reason" : { "state" : "xyz" } or "reason" : { "attribute" : "xyz" } or "reason" : { "argument" : "xyz" } . The author has to know which one it is when they write it, why not save some processing time, both for the software itself and for later readers when they try to figure out what they're looking at?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/synthetichealth/synthea/pull/121#issuecomment-269632285, or mute the thread https://github.com/notifications/unsubscribe-auth/AIO2lIvrhSMjFf6d1T8SCToOZ9sVz4c4ks5rM7oDgaJpZM4LWgP6.

Here’s a trace of the recursive test package. A little trickier but overall this still seems like a reasonable capability. It will be a huge effort to refactor the other modules to employ submodules, but they can be enhanced as needed for additional functionality. The lines beginning with small integers record the number of iterations the test has done. I jump the simulation date forward around the delays so you can see when the various events are recorded they have occurred at points in time past the delays.
Jeff
1 TestPerson [0] Initial [Initial]
2016/12/29 14:48 TestPerson [0] Example_Condition [ConditionOnset]
2016/12/29 14:48 TestPerson [0] CallSubmodule [submodule=Encounter Submodule]
2 TestPerson [0] Initial [Initial]
2017/12/29 14:48 TestPerson [0] Delay [Delay]
3 TestPerson [0] Delay [Delay]
2017/12/29 15:48 TestPerson [0] Encounter_In_Submodule [Encounter]
TestEncounterEvent [name=Encounter_In_Submodule]
2017/12/29 15:48 TestPerson [0] CallSubmodule [submodule=MedicationOrder Submodule]
5 TestPerson [0] Initial [Initial]
2017/12/29 15:48 TestPerson [0] Examplitis_Medication [MedicationOrder]
TestMedication [name=Examplitis_Medication]
2018/01/12 15:48 TestPerson [0] Delay_Yet_Again [Delay]
6 TestPerson [0] Delay_Yet_Again [Delay]
2018/01/12 15:48 TestPerson [0] End_Medication [MedicationEnd]
2018/01/12 15:48 TestPerson [0] Med_Terminal [Terminal]
2018/02/23 14:48 TestPerson [0] Delay_Some_More [Delay]
7 TestPerson [0] Delay_Some_More [Delay]
2018/02/23 14:48 TestPerson [0] Encounter_Terminal [Terminal]
2018/02/23 14:48 TestPerson [0] End_Condition [ConditionEnd]
2018/02/23 14:48 TestPerson [0] Terminal [Terminal]
Encounter 0 Events:
TestCondition [name=Example_Condition]
TestEncounterEvent [name=Encounter_In_Submodule]
TestMedication [name=Examplitis_Medication]

On Dec 29, 2016, at 10:57 AM, Jeastman<EMAIL_ADDRESS>wrote:
I think its working for this limited test case. In this test, the first Encounter has the ConditionOnset and the MedicationOrder. From the trace, you can see that the subModule waits for the next wellness encounter (patient age = 0 so its not long). Context isn’t too hairy in my implementation as I’m just cloning the modules.
Need more test data!
Jeff
0 TestPerson [0] Initial [Initial]
2016/12/29 11:50 TestPerson [0] Encounter [Encounter]
1 TestPerson [0] Encounter [Encounter]
TestEncounterEvent [name=Encounter]
2017/01/05 10:50 TestPerson [0] Examplitis [ConditionOnset]
2017/01/05 10:50 TestPerson [0] CallSubmodule [CallSubroutine]
2 TestPerson [0] Initial [Initial]
2017/01/05 10:50 TestPerson [0] MedicationOrder [MedicationOrder]
TestMedication [name=MedicationOrder]
2017/01/05 11:50 TestPerson [0] Wellness [Encounter]
3 TestPerson [0] Wellness [Encounter]
2017/01/28 20:50 TestPerson [0] Sub_Terminal [Terminal]
2017/01/28 20:50 TestPerson [0] Main_Terminal [Terminal]

On Dec 29, 2016, at 10:14 AM, Jeastman<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
+1 I think the concept is very useful and I’m experimenting with an implementation. The idea of passing (binding) states from a parent module into a subModule makes sense to me, and Codes would be useful too. The curly brackets mechanism for denoting an argument is ok with me until we gain more experience with subModules. Its nice to be OO but Ruby’s ability to dynamically add fields&methods to objects makes my static Java world a little more challenging.
I’ll add more thoughts as I wade into this a bit more.
Jeff

On Dec 29, 2016, at 8:47 AM, dehall<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I'm definitely in favor of the concept of submodules but I'm not sure about this implementation. My biggest concern is the additional complexity this adds to running modules. Context is already the most complicated class and this adds another level on top of that.
The concept of passing arguments is interesting, but it feels too limited in what it can do. Take a look at the Allergies module: #120 https://github.com/synthetichealth/synthea/pull/120 The main core of the module is 3 states repeated 7 times with different values. With a more powerful system this could be represented a submodule of those 3 different states, and the different codes and percentages passed in as parameters. But I realize something like that can get too complex for people to read and follow so I guess there are tradeoffs.
The use of curly brackets around the name of an argument feels like a hack instead of using more traditional OO methods. Maybe this isn't the will of the team but I'm in favor of being more strict and explicit in the models rather than having 1 field be potentially multiple things which all have to be checked at runtime. Instead of "reason" : "xyz" where xyz could be a state name, attribute, or argument, I'd much rather see "reason" : { "state" : "xyz" } or "reason" : { "attribute" : "xyz" } or "reason" : { "argument" : "xyz" } . The author has to know which one it is when they write it, why not save some processing time, both for the software itself and for later readers when they try to figure out what they're looking at?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/synthetichealth/synthea/pull/121#issuecomment-269632285, or mute the thread https://github.com/notifications/unsubscribe-auth/AIO2lIvrhSMjFf6d1T8SCToOZ9sVz4c4ks5rM7oDgaJpZM4LWgP6.

I removed args from the CallSubmodule state. In 99% of meaningful use cases the args were just used to pass the name of the most recent Encounter state for a clinical state in the submodule to use as a target_encounter.
Now, Synthea instead infers the correct target_encounter for a clinical state by checking to see if an encounter was recently processed and is concurrent with the clinical state in question. This encounter is known as the current_encounter in each module's context. This makes target_encounter optional (and in fact, unused) for all clinical states except ConditionOnset and AllergyOnset. In a future release we should probably remove the target_encounter property from those states. For now, however, I left target_encounter as an optional property to maintain backwards compatibility with our existing modules.
In some cases, target_encounter can also be optional for OnsetStates if they directly follow an Encounter state. In practice this rarely occurs though. In all cases, if a current_encounter cannot be found for a clinical state an exception is raised.

+1 This does seem reasonable. Its only when ConditionOnset and AllergyOnset need to refer to future states that target_encounter is needed as you’ve noted. And, by eliminating the args on the Call_Submodule state it cleans up the {encounter} hygiene issues. Other arguments can be passed via attributes if they are needed. The changes to my implementation were minimal.
Jeff

On Jan 12, 2017, at 12:30 PM, Carlton Duffett<EMAIL_ADDRESS>wrote:
I removed args from the CallSubmodule state. In 99% of meaningful use cases the args were just used to pass the name of the most recent Encounter state for a clinical state in the submodule to use as a target_encounter.
Now, Synthea instead infers the correct target_encounter for a clinical state by checking to see if an encounter was recently processed and is concurrent with the clinical state in question. This encounter is known as the current_encounter in each module's context. This makes target_encounter optional (and in fact, unused) for all clinical states except ConditionOnset and AllergyOnset. In a future release we should probably remove the target_encounter property from those states. For now, however, I left target_encounter as an optional property to maintain backwards compatibility with our existing modules.
In some cases, target_encounter can also be optional for OnsetStates if they directly follow an Encounter state. In practice this rarely occurs though. In all cases, if a current_encounter cannot be found for a clinical state an exception is raised.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/synthetichealth/synthea/pull/121#issuecomment-272227578, or mute the thread https://github.com/notifications/unsubscribe-auth/AIO2lEVuAT4OwFm7UTUcaPf_NIN9cxU2ks5rRmMcgaJpZM4LWgP6.

That's All Folks!
@dehall, thanks for pushing me to simplify and revise this. I think you'll be happy with the final result. In summary:

I squashed all commits into one, comprehensive commit. With all of the iterations my commit history got ugly.

I removed the Package and ContextRunner classes and placed everything under Context. A lot of redundant stuff disappeared in the process.

The CallSubmodule state now uses Context.call_submodule() to invoke a submodule and continue processing states.

The Terminal state now uses Context.return_from_submodule() to terminate a submodule and continue processing states in the parent module.

I created a global module lookup, Synthea::MODULES, that all modules/submodules are loaded into before execution begins. Since submodules are frequently reused, this ensures that each and every module and submodule is loaded only once.

A Context is now initialized using a key to a module in Synthea::MODULES. For example:
ctx = Synthea::Generic::Context.new('allergies')

Where the allergies module is already loaded into Synthea::MODULES['allergies'].

I had to disable static validation of references to states.

Static Validation Issues
With the introduction of submodules, modules may now reference states that are not necessarily in the same file. Since we statically validate only one module file at a time, our approach for validating those references no longer works.
However, we are still able to validate:

That every state in the module is reachable
That every state's required fields are satisfied

This still holds true for every module and submodule.
Future Considerations
In the near future (but in separate PRs) I recommend we also do the following:
Upgrade static validation of modules to support submodules
In my opinion, any module that uses submodules should also have those submodules validated with it. For example, if the ear_infections module uses the otc_pain_reliever submodule and the injuries module also uses the otc_pain_reliever submodule, each pair should be validated separately. This means the otc_pain_reliever module may be validated repeatedly, but in different contexts.
Upgrade graphviz to support submodules
Graphviz should make a distinction between modules and submodules and group them appropriately in separate directories. As it stands now, all modules/submodules are rendered and placed in the output directory.
Use submodules!
For starters, I think a few medication submodules would be a good first step. I think common, shared submodules for over-the-counter pain relievers, over-the-counter antihistamines, opioid pain relievers, and antibiotics would be immediately useful.


[Bug] 挂载AREX导致OSS上传文件失败

Search before asking

[X] I have searched the existing issues before asking.

AREX Test Service
AREX Java Agent (arextest/arex-agent-java)
Current Behavior

Expected Behavior
1
Steps To Reproduce

Anything else
1
Are you willing to submit a pull request to fix on your own?

[X] Yes I am willing to submit a pull request on my own!

thanks your feed, you can exclude uploadFile operation record firstly, we not recommend record upload\download operation.

This may be  caused by pinpoint, see this issues https://github.com/pinpoint-apm/pinpoint/issues/4667
I tried his way, modify config, it works
profiler.apache.httpclient3.io=false
profiler.apache.httpclient4.io=false


Add create package script

Adds the create-package label support that will auto-generate packages that can be used to test PRs before they get released.
Also adds some vscode files to simplify testing a bit.

oops, wrong repo!


使用zhipuai报错

2024-06-28 16:01:37.363 | ERROR    | metagpt.utils.common:log_it:554 - Finished call to 'metagpt.actions.action_node.ActionNode._aask_v1' after 0.153(s), this was the 1st time calling it. exp: Request failed, msg: {"error":{"code":"1002","message":"Authorization Token非法，请确认Authorization Token正确传递。"}}, please ref to https://open.bigmodel.cn/dev/api#error-code-v3

to confirm you have wrote right api_key or check the system timezone to make sure it's in GMT+8


add support for relative step sizes

@dilpath Which of the tests are expected to pass? I think the ones expected to fail should either xfail, or be moved to a separate pull request.

Thanks for the various PRs @FFroehlich! Unfortunately, there is a redesign of this package (the redesign branch, examples in [1]), which has various improvements, and I was waiting for feedback on it via #16 before merging. However, I didn't anticipate others submitting additional PRs in the meantime.
I intend to incorporate the work done in your PRs into redesign. Is there a time-critical element to this -- would you like to have these PRs merged into main soon? If so, I can review them now, ignoring the redesign for now.
[1] https://github.com/ICB-DCM/fiddy/blob/redesign/examples/derivative.ipynb

done in #20


Fix grammar and errors in Object doc.

I believe C# has a special export syntax, but not c++.
"Objects" should either be "Object" or "Object's". I opted for the former.
The overall structure of the sentence wasn't gramattically correct.

Closing in favor of https://github.com/godotengine/godot/pull/67880. I just mis-parsed the sentence. Sorry!


Buttons cursor for "disabled" state is wrong

Can you move button default cursor to variable to be setup according to taste?
Current obligatory button { cursor: pointer } breaks proper button behavior - disabled buttons should not be indicated as clickable. What is well done in bootstrap 4, is broken in CoreUI.
I respect your approach, and some cases will go fine with this, but this is counter-intuitive especially for "new users". They are not able to distinguish disabled state only from "bleached color", as they are not familiar with color scheme.

This issue have been fixed.


Failed to fetch git data for MMM-GoogleAssistant: Error: block timeout reached

After starting MM I get this error: Failed to fetch git data for MMM-GoogleAssistant: Error: block timeout reached
also in the other terminal I have opened assistant.py file but google assistant is not responding

Same issue here


hide-view-on-map

Oh i didnt see that we have class for this already, ive made changes

Thank you @Farelion!


Update docs: aws-lambda plugin

In sync with this PR: https://github.com/Mashape/kong/pull/2823.

Hey there,
I just deleted the base branch against which this PR was open, which in turn closed this PR - sorry for the confusion! I think we'll go with #506!

Thanks


API Docs

Was checking stuff before submitting a new device (curtain/blinds switches), with additional info and discovered this repo, by the makers of ewelink:
https://github.com/CoolKit-Technologies/apiDocs
Seems they are documenting, at least that seems, the API (although in chinese).

WOW! many thanks!
Thanks to @2016for I've got ahold of a similar API docs version before, but this one seems fresh-er and looks like someone actually is pushing some the pages translated in english too!

Yep, there are pushes of almost all API in english. Forked it, to prevent dissapearances :-D


Line break in LOCAL_CODE configuration variable.

Context
The creation of Gitolite-Hooks are not working correctly. That is they get not created correctly. If found a solution myself which I will describe in the following text.
Code Context
I am talking about this line of code.
Problem
My hooks did not get registered and I searched thru all my settings and the code and finally found that it was trying to copy the hook files to a path that contains a line break, which was caused by this line of code as the variable has contained a line break at its end.
Solution
I fixed it for myself by appending .rstrip to the code line to remove the last blanks (and also line breaks!).

Hi! Thanks for your report, but this issue is already fixed : https://github.com/jbox-web/redmine_git_hosting/commit/348d9249aceb491540a69d59cbf426046bef54ed
It's part of the next 1.2.3 release. Stay tuned!

Oh, I have not seen that commit. I looked up nearly every branch but not the release branch (-es)… My mistake :)

No problem, very nice job 👍


[Security] bump all deps with<EMAIL_ADDRESS>or lower

This is a more aggressive PR bumping all versions that depend on<EMAIL_ADDRESS>or lower.  Unfortunately this required bumping babel-X packages to @babel/ and required config changes.

See #1838 as well as #1737.
There's no security issue in this package wrt use of older lodash.

Also, updating to babel 7 will fail tests in older node versions that remain supported by this package.


 Simple CSS fix, maybe?

Hi, do you mind if I have a look at this?


which arg for android

You have linux and win args in your repo. which are you using for android ??
I have read the
/ABOUT_GN_ARGS.md
but it's to global and more explanations for Linux/Win/Mac  (I think)

https://github.com/Alex313031/thorium/blob/main/arm/android/android_ARM32_args.gn
https://github.com/Alex313031/thorium/blob/main/arm/android/android_ARM64_args.gn
https://github.com/Alex313031/thorium/blob/main/arm/android/android_x64_args.gn
https://github.com/Alex313031/thorium/blob/main/arm/android/android_x86_args.gn
4 of the above
@LeOS-GSI

Nice, thanks

Von: Ho Cheung @.>
Gesendet: Sonntag, 1. Oktober 2023 17:19
An: Alex313031/thorium @.>
Cc: harvey186 @.>; Mention @.>
Betreff: Re: [Alex313031/thorium] which arg for android (Issue #228)
https://github.com/Alex313031/thorium/blob/main/arm/android/android_ARM32_args.gn
https://github.com/Alex313031/thorium/blob/main/arm/android/android_ARM64_args.gn
https://github.com/Alex313031/thorium/blob/main/arm/android/android_x64_args.gn
https://github.com/Alex313031/thorium/blob/main/arm/android/android_x86_args.gn
4 of the above
@LeOS-GSIhttps://github.com/LeOS-GSI
—
Reply to this email directly, view it on GitHubhttps://github.com/Alex313031/thorium/issues/228#issuecomment-1742113162, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAUZVLW5SF6KOBDWE77ODZLX5GCYHANCNFSM6AAAAAA5OKYZYY.
You are receiving this because you were mentioned.Message ID: @.***>

Nice, thx


Log bad PeerId format

Motivation

This issue https://github.com/ChainSafe/lodestar/issues/4246 is hard to debug as we don't know the format of the string that was considered invalid

Description
Wrap conversion and log error in case it's invalid
@wemeetagain maybe in #4246 there was a mix of different encodings used? Is it possible to commit to use PeerId or PeerIdStr everywhere?

Is it possible to commit to use PeerId or PeerIdStr everywhere?

at least for now, libp2p plans to use PeerId objects (although i'm still an advocate for https://github.com/libp2p/js-libp2p/issues/680)
I'd still recommend we use PeerIdStr everywhere in lodestar .
Else we'd need to convert all Map<PeerIdStr, T> to PeerMap


rename table title to CPU (from %CPU) and siplay the percentage just next to the value

instead - do the:
CPU
1%
2.24%
...
got it?

done (thanks kopi)


Another publication error was found in the document

Sandcastle example: None
Browser: All
Operating System: All

https://cesium.com/learn/3d-tiling/on-prem/on-prem-reality-tiler/

Thanks @danchaotaiyang! I've passed along this issue to the relevant tracker.


Sass emits an error when it needs to log something

Summary
Anytime sass needs to log to stderr, it breaks. It's actually the same error that we get without the custom importer.
Scenarios

[ ] Sass Exception (eg. syntax error)
[ ] Debug statements - @debug message
[ ] Warn statements - @warn message
[ ] Error statements - @error message

Notes

Sass has a logger option, which we could use to fix the debug and warn scenarios. See the docs.
We could replicate the actual sass logger. See the code.

Note: It seems that the logger only covers debug and warn statements. For error statements and sass exceptions, it might work to compile the input, catch any errors, format them, and log them.


Automate download and unzip of the model file

Also added the Exception to the log message when the ImageClassifier fails to initialize. :-)  When the model file is missing the Logcat error is now much more helpful:
Failed to initialize an image classifier. java.io.FileNotFoundException: mobilenet_quant_v1_224.tflite
        at android.content.res.AssetManager.openAssetFd(Native Method)
        at android.content.res.AssetManager.openFd(AssetManager.java:329)
        at com.example.android.tflitecamerademo.ImageClassifier.loadModelFile(ImageClassifier.java:137)

TESTING
Used Android Studio 3.0.1 and started with a ./gradlew clean.  I was able to launch on a Samsung S8+ and successfully use the app.
Doing a ./gradlew clean then a command line build shows the download is happening before the build:
$ ./gradlew assemble
<snip>
:app:downloadModel
Downloading https://storage.googleapis.com/download.tensorflow.org/models/tflite/mobilenet_v1_224_android_quant_2017_11_08.zip
:app:unzipModel
Unzipping build/intermediates/mobilenet_v1_224_android_quant_2017_11_08.zip
:app:preBuild
:app:preDebugBuild
<snip>
:app:assembleRelease UP-TO-DATE
:app:assemble UP-TO-DATE

BUILD SUCCESSFUL

Running it a second time does not download the model again:
:app:downloadModel UP-TO-DATE
:app:unzipModel UP-TO-DATE

Can one of the admins verify this patch?

@daj can you resolve the merge conflict

I've updated the pull request and rebased onto the latest master.

Jenkins, test this please.

@aselle WDYT?

Nagging Reviewer @aselle: It has been 41 days with no activity and the awaiting review label was assigned. Can you please take a look?

@aselle please can you review?  I can update the PR to resolve the conflict, but I only want to do that if this will get reviewed.  Thanks!

Nagging Reviewer @aselle: It has been 14 days with no activity and the awaiting review label was assigned. Can you please take a look?

Nagging Reviewer @aselle: It has been 37 days with no activity and the awaiting review label was assigned. Can you please take a look?

@daj could you pull rebase and push again?
@aselle WDYT?

I opened this pull request 6 months ago, and I already rebased it once during that time.  I'd like to hear from a reviewer that they intend to review and merge it before I spend any time doing more rebasing.  Thanks!

@shashishekhar I rebased again and resolved another conflict.  Hopefully we can get it merged before things change again. :-)

All tests pass. Woohoo!


Game fails to mount Team Fortress 2 through an external drive as of Revisions 8-9

The paths to TF2 have to be manually declared through gameinfo.txt in order to boot the game, otherwise "Your server is not mounting Team Fortress 2 correctly" will appear as an error message preventing the game from launching as normal.

A workaround is by modifying the gameinfo.txt to have the exact paths.


Generate new public

Same changes as seen in #59, except generated from private wdl.
Also includes a docker version bump.

@sooheelee, @vdauwera is comms in charge of this repo? if so, we should probably add you guys to the pull approve.

@vivster7 They own the repo now although I'm sure you could get one of us to opine if in a time crunch

@geoffjentry, I think comms should look at the PR, thanks though.

Will take a look tomorrow, thanks

Just a question @vivster7. For the changes to the code to be effective, does one need to use the updated Docker? Or will the new code changes work fine in the original Docker?

The original Docker would work as well for these specific changes. The docker change bumped the GATK version from 3.6-2-g69af359 to 3.6-44-ge7d1cd2 -- it should have no effect on the public wdl since we GATK36 is not used in the public WDL.
Unsure why your diff is showing a change for --read_filter. Did you run diff PublicPairedSingleSampleWf_160927.wdl archive/PublicPairedSingleSampleWf_160720.wdl?

@vivster7 I just used diff on my terminal. Hmm.
Another question, I'm using docker inspect and see we reverted to a prior minor release of Java:
<                 "JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre",
<                 "JAVA_VERSION=8u91",
<                 "JAVA_DEBIAN_VERSION=8u91-b14-1~bpo8+1",
---
>                 "JAVA_VERSION=8u66",
>                 "JAVA_DEBIAN_VERSION=8u66-b17-1~bpo8+1",

Is this intentional? If so, I'm curious to know why, e.g. if it impacts GATK tool performance.
Other changes include changing Docker version from 1.8.1 to 1.8.2, and as you say, upping our GATK36 version.

The Java and Docker version changes were unintentional, and I believe not harmful as well (its currently the Docker image we use to run production).

Would like to get this closed out. @vdauwera, do you also want to review this?

Yes, will do in the next hour.

@vivster7 Sorry for the delay in reviewing this. Just a couple of nitpicks.

For all files (not just the wdl), rather than rename the original files to the new timestamp, we prefer to move the originals to the archive directory, and create new files with the new timestamp. That allows git-naive users to easily find older versions (eg to replicate someone else's findings) without having to look at the git history. The older wdl versions in the archive don't have all the associated files because we hadn't generated them for those wdls, but we do want to do this for all the files going forward.

Did you generate the new public WDL from the private one using Kate's script, or did you apply the same modifications independently to both? There may have been a few other tweaks to the private WDL that we didn't yet copy over (because they were too minor to warrant it) and I'd like to make sure that the private and public don't accumulate any divergences (which is why we have Kate's script).

The inputs and options files are the exact same, so I'll just copy them over with the old name so they can be tied to the old wdl

I used Kate's script to generate this wdl

Great, thanks @vivster7. Just one more question related to the seq_cache_populate.pl script.

Great,  all good then :+1:


Expose ledger metrics (number of accounts, owner objects) (Version: 1.7/1.8?)

Summary
rippled exposes several statistics via its CLI and API. It would be great to have a new per-ledger metrics command/api (such as number of accounts, owner objects, escrows). If rippled is already aware of these numbers on a per-ledger basis, it would be easy to return this info.
Motivation
It would be great if explorers can plot these numbers on a chart and visually depict ledger growth over time.
Solution
Does rippled track counts of various objects? If yes, we'd like to fetch it!
Paths Not Taken
Fetching raw ledger and iterating through its contents - this easily takes more than 4 seconds and it computationally intensive.

I don't see how this would be calculated for an older ledger that's no longer cached other than either keeping a database with these metrics around (complex) or by querying the full ledger and counting the objects (expensive). Calculating this from API calls and caching these (static) values in a local database would be a great external project. I don't see how this would be a performance difference compared to adding it into rippled itself, except for maybe the most recent ledger(s) at most.

I don't see how this would be calculated for an older ledger that's no longer cached other than either keeping a database with these metrics around (complex) or by querying the full ledger and counting the objects (expensive). Calculating this from API calls and caching these (static) values in a local database would be a great external project. I don't see how this would be a performance difference compared to adding it into rippled itself, except for maybe the most recent ledger(s) at most.

@cjcobb23 @mtrippled Is this something reporting mode could do more efficiently?

@cjcobb23 @mtrippled Is this something reporting mode could do more efficiently?

Reporting mode can do something like this, though I don't know if it should. We would need to store these metrics in a database, or somehow change the way we store data. This adds complexity to the ETL process, and thus there is a limit to the number of metrics that we could track. @gnurag could you list out all of the metrics that you are looking for?
Really this is something that belongs in a different layer than rippled or reporting mode. One way to do this via RPC is as follows:

Use ledger_data to page through an entire ledger, populating a database with whatever metrics are needed.
For each new ledger, call ledger with transactions and expand set to true. This will return the transactions with their metadata. Parse the transaction metadata to determine which ledger objects were added, modified or deleted as part of applying the transactions in this ledger.

The above method should allow you to track whatever metrics are necessary. Feel free to ask any questions if the method is unclear.

Reporting mode can do something like this, though I don't know if it should. We would need to store these metrics in a database, or somehow change the way we store data. This adds complexity to the ETL process, and thus there is a limit to the number of metrics that we could track. @gnurag could you list out all of the metrics that you are looking for?
Really this is something that belongs in a different layer than rippled or reporting mode. One way to do this via RPC is as follows:

Use ledger_data to page through an entire ledger, populating a database with whatever metrics are needed.
For each new ledger, call ledger with transactions and expand set to true. This will return the transactions with their metadata. Parse the transaction metadata to determine which ledger objects were added, modified or deleted as part of applying the transactions in this ledger.

The above method should allow you to track whatever metrics are necessary. Feel free to ask any questions if the method is unclear.


Usage With Browser & Node

How can I install this and use in a package that runs both in node and the browser?
I am getting a build error with the domino dependency when building with NextJS.
app:build: Error:
app:build:   × With statement are not allowed in strict mode
app:build:     ╭─[/webapp/node_modules/.pnpm/domino@2.1.6/node_modules/domino/lib/sloppy.js:7:1]
app:build:   7 │ module.exports = {
app:build:   8 │   Window_run: function _run(code, file) {
app:build:   9 │     if (file) code += '\n//@ sourceURL=' + file;
app:build:  10 │     with(this) eval(code);
app:build:     ·     ────
app:build:  11 │   },
app:build:  12 │   EventHandlerBuilder_build: function build() {
app:build:  13 │     try {
app:build:     ╰────

Everything is working fine with the package build for the NodeJS server but the NextJS app is saying no thanks.

I have this exact issue aswell... TypeError: Right-hand side of 'instanceof' is not an object

Just released version 7.2. Please let me know if that fixes the problem.

Just released version 7.2. Please let me know if that fixes the problem.

Works perfectly! :) Thank you!


[docs] Prepare the v1 release

This time, it's the version page.

We also need to reenable the network code, and update the versions.json file, that that the v1 docs can forward reference future releases.

Also, what's your definition of "stable" in this context

Okay, might be best just to call them "releases" then. 😄
I'll sort the network code. Not sure why it got commented out, but that's easily fixed.


Remove: wgyt.wgyttk version 0.1.0

Url 404, no idea where the package moved

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Does your manifest conform to the 1.0 schema?

Resolves #37381

Microsoft Reviewers: Open in CodeFlow

I guess the author deleted the repository because


[WIP] Log rules

This PR adds documentation for Calico Log action policies.
Draft changes to log-rules.mdx

Continues work originally submitted in #1777 .

Product Version(s):

Issue:

Link to docs preview:

https://deploy-preview-1827--calico-docs-preview-next.netlify.app/calico/next/network-policy/policy-rules/log-rules
SME review:

[ ] An SME has approved this change.

DOCS review:

[ ] A member of the docs team has approved this change.

Additional information:

Merge checklist:

[ ] Deploy preview inspected wherever changes were made
[ ] Build completed successfully
[ ] Test have passed

Lgtm


CAT compatible with OS X 10.11.4

I have the MBA 11' mid 2011 with 10.11.3 and CAT installed. Everything is working normally, including Hands Off and Continuity.
Just updated the OS X to 10.11.4.
Everything still works fine.

MB Pro 15' early 2011 running public 10.11.4 (with replaced CAX). iOS 9,3 iPhone 6 Plus. Everything work - Handoff, Airdrop, Modem. What I did on MB. Installed update. Rebooted with CMD+R. Checked SIP. It was still disabled. Rebooted normally. Started CAT and installed it. As I said above everything work.

MBA 13' mid 2011 with  OSX 10.11.4 and CAT installed, well-activated. Everything is working normally except Airdrop.  I've already added my infos as a new contact in my own contact book as some others suggest. However the Airdrop doesn't work. Any ideas ?

Same here!
Everything works well except Airdrop.
And thats the most important feature for me…

On 28 Mar 2016, at 5:44 AM, xmangel<EMAIL_ADDRESS>wrote:
MBA 13' mid 2011 with OSX 10.11.4 and CAT installed, well-activated. Everything is working normally except Airdrop. I've already added my infos as a new contact in my own contact book as some others suggest. However the Airdrop doesn't work. Any ideas ?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/dokterdok/Continuity-Activation-Tool/issues/290#issuecomment-202150906

Did you try to make new pairing in bluetooth setting?

MBP 15" 2010 with replaced AirPort (BCM94331PCIEBT4CAX) everything works on public 10.11.4