fixed the issue of the jobs page loading slow by getting only the rec…

…ent job versus getting all jobs from the database
tested it and a big improvement in performance with 4000+ jobs. I have not implemented the part where an additional finished date is added to the jobs table as per your last comment. will work on that next.

Please add finished time stamp but as a separate pull request.
Sent from my iPhone

On Jun 3, 2016, at 1:43 PM, Akshatha Pai<EMAIL_ADDRESS>wrote:
…ent job versus getting all jobs from the database
tested it and a big improvement in performance with 4000+ jobs. I have not implemented the part where an additional finished date is added to the jobs table as per your last comment. will work on that next.
You can view, comment on, or merge this pull request online at:
https://github.com/eurekaclinical/eureka/pull/87
Commit Summary
fixed the issue of the jobs page loading slow by getting only the recent job versus getting all jobs from the database
File Changes
M eureka-common/src/main/java/edu/emory/cci/aiw/cvrg/eureka/common/comm/JobFilter.java (14)
M eureka-common/src/main/java/edu/emory/cci/aiw/cvrg/eureka/common/comm/clients/ServicesClient.java (7)
M eureka-protempa-etl/src/main/java/edu/emory/cci/aiw/cvrg/eureka/etl/dao/JobDao.java (2)
M eureka-protempa-etl/src/main/java/edu/emory/cci/aiw/cvrg/eureka/etl/dao/JpaJobDao.java (39)
M eureka-protempa-etl/src/main/java/edu/emory/cci/aiw/cvrg/eureka/etl/resource/JobResource.java (28)
M eureka-protempa-etl/src/test/java/edu/emory/cci/aiw/cvrg/eureka/etl/resource/JobResourceTest.java (2)
M eureka-services/src/main/java/edu/emory/cci/aiw/cvrg/eureka/services/config/EtlClient.java (2)
M eureka-services/src/main/java/edu/emory/cci/aiw/cvrg/eureka/services/config/EtlClientImpl.java (8)
M eureka-services/src/main/java/edu/emory/cci/aiw/cvrg/eureka/services/resource/JobResource.java (25)
M eureka-services/src/test/java/edu/emory/cci/aiw/cvrg/eureka/services/config/MockEtlClient.java (5)
M eureka-webapp/src/main/java/edu/emory/cci/aiw/cvrg/eureka/servlet/JobListServlet.java (2)
M eureka-webapp/src/main/java/edu/emory/cci/aiw/cvrg/eureka/servlet/JobPollServlet.java (2)
Patch Links:
https://github.com/eurekaclinical/eureka/pull/87.patch
https://github.com/eurekaclinical/eureka/pull/87.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Looks like you need to edit JobFilter.toQueryParam() so that it includes the value of latest.


Add a way to disable transit

OTP right now is the biggest memory hog by far, so it would be nice to let people disable it if they don't have memory to spare.

This is a really naive question, for which I apologize, but would it be feasible to have this be a run-time loadable module?  Such that if a person didn't often use transit, but did once in a while, the transit module could be loaded (at, presumably, considerable one-time expense), and then flushed after some period (a couple of hours?) of inactivity, or when more pressing needs for that memory arose?  From a social-responsibility perspective, having instances which are never able to supply transit directions, and thus make transit directions unpredictably available, would be a disincentive to transit use, which would be a bad thing.

Not naive! The issue with that is building the OpenTripPlanner index requires a one-time cost in latency that's completely unacceptable for an end-user, and moveover the machine running the stack might not be able to spare the RAM to build the graph or run OTP.


OpenID auth broken in jwtUtil

Moving from v0.6.3 to master, it looks like the OpenID auth was refactored into jwtUtil. However, this no longer works with providers that do not use unique_name by default such as Google. In v0.6.3, any valid claim was used as the username, while in v0.7.0 only the claim unique_name is allowed to be the username. See,
https://github.com/HDFGroup/hsds/blob/9e1f08183f6f5e7ad51c57a6d2e7ba0ecfd95f02/hsds/util/jwtUtil.py#L177-L191
The v0.6.3 behavior wasn't great so I understand why it was changed, but this needs to be configurable. Possible options:

The first listed claim is used as the username field (possibly only if unique_name isn't present)
Add a new config option openid_username_claim and maybe also openid_roles_claim

@jjaraalm - thanks for reporting this!
I don't have an easy way right now to test with OpenID auth - would you be willing to create a PR for the fix?
I can verify against Azure AD.
Slightly favor the first approach to have less tweaking of config settings needed by deployers.

I'll think about putting a PR in, but it's not the highest priority for me right now.


Docs Bash - Extractors and Loaders

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/680
Originally created by @derek-knox on 2019-06-04 22:11:42

Documentation bash cleanup effort. In this case the Extractors and Loaders section

View 2 previous comments from the original issue on GitLab


Add definition for exhibitNumber

References:

[ONT-436] (CP-35) exhibitNumber does not have a definition

Signed-off-by: Alex Nelson<EMAIL_ADDRESS>

@plbt5 - this is not an RDF identifier.  We intentionally allow any string to allow investigators to deploy their own identifier policies.  We appreciate this means there's a lack of enforcement of "Unique identifier".


Fix regression: Returning "null" for empty matrix results in some cases.

Seems like https://github.com/prometheus/prometheus/commit/2f03acbafc08dd83cc8a5c3d94b2f071bb34f809 introduced a regression where where we before returned [] results we are not returning null on the serialized response:
To reproduce we can run a simple range query with bottomK and a metric that does no exists (ex: bottomk(2, doNotExists):
Before:
{"resultType":"matrix","result":[]}

After the change:
{"resultType":"matrix","result":null}

This is problematic as the prometheus client cannot deserialize this results as we can see on this screenshot and on cortex fuzzy testing (we found the issue when updating prometheus on cortex):
https://github.com/cortexproject/cortex/actions/runs/8826947786/job/24233899882

Im not sure if this is the right fix but im creating the issue anyway to highlight the issue.
cc @bboreham

we are not returning null on the serialized response

I assume you mean we are now returning null on the serialized response?

👋
Is this something we want to include in the 2.52 release? If yes, could you change the base branch to 'release-0.52'?

👋
Is this something we want to include in the 2.52 release? If yes, could you change the base branch to 'release-0.52'?

I don’t think this change was included in the release .. I may be wrong .

we are not returning null on the serialized response

I assume you mean we are now returning null on the serialized response?

Yeah… I will update the description :)

I don’t think this change was included in the release .. I may be wrong .

Isn't Bryan's commit part of the release-2.52 branch? @ArthurSens WDYT?

Yeah, I believe it does 😬. v2.52 is the only release branch with the buggy commit

Wow nice git-fu there @ArthurSens, I didn't know it.

ref #13744

I have proposed an alternative fix in #13997, which I think is a more general approach.

Closing this in favor of https://github.com/prometheus/prometheus/pull/13744


Disk Status Monitor ready or not?

When the disk failed ，Is Hwameistor can be monitored or not?

when it is Physical disk，the SMART  info can be collected ,and with dashboard such as grafana，the status can be viewed
when it is Raid，the function is developing，Q1~Q2 can be ready

Disk health monitor is ready now, metrics of disk health info are exposed now.


TS2339 refactoring warnings (three gray dots) appearing under javascript properties

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.60.2 (user setup)
OS Version: Windows 10 Pro 20H2, 19042.1165, Windows Feature Experience Pack 120.2212.3530.0

Steps to Reproduce:
I have a JavaScript file. It declares & defines a variable in the topmost scope, like const options = {};
Then, at some dynamic point during runtime, user configuration values (properties) are cloned from local storage into this options object:
for (const [key, field] of Object.entries(storage)) options[key] = field.value;
So obviously TypeScript validator thinks options.blahblah does not exist. Which is fine, I don't expect it to. But instead of just creating a lightbulb icon to the left when I click on its general area, it adds 3 dots under the beginning of the property name, which appear no matter what I do. They're showing 100% of the time. When I have dozens of properties being referenced all over the place, these little dotted underlines cause a large amount of visual clutter.
It's irritating because there's nothing wrong with my script, but vs code keeps treating it as somehow erroneous and shoving it in my face. It doesn't give me any valuable refactoring suggestions either. Astonishingly, it clutters my document with a hundred of these warnings, only to recommend "extracting to Fluent files" in each case. Obviously that suggestion is completely irrelevant to my use case.
 When I originally wrote this script some months ago, and validated it with ESLint, these gray dots did not exist. It's only when I came back to update it that I noticed the warnings. Naturally I went digging through the settings, but could not find anything that sounded relevant. I did some google searches and found people talking about other representations of the same rule (2339) in vs code extensions. But I couldn't find any solution or suggestion for disabling it in the TS/JS validator of vs code proper.
So I just went ahead and started blindly unchecking boxes in the settings. I figured eventually I'd reload vs code and see the dotted underlines are gone, but no such luck. So I'm wondering if a setting to disable this even exists.
Thank you 🙏

Please share a self contained block of code that demonstrates the issue

Oh, thought I already did. Is this better?
let a = {};
let b = {
    apple: true,
    banana: false,
    grape: undefined,
    lychee: null,
};
for (const [key, val] of Object.entries(b)) a[key] = val;
console.log(a.apple);

If that's unclear you can take a look at the greasemonkey script I described in my first post, which was suddenly filled with dotted underlines a month or two ago.
To be clear, I don't expect VS code to recognize that the for loop I described above would define apple on a. I understand that would be substantially more computationally expensive than what it's currently doing. I just want some way to turn off the 3 dots display, because it's making my editors so cluttered and causing me to waste time reexamining code that isn't defective, for an alert that offers no refactoring suggestions anyway.
However, I would prefer if there was a way to keep the 3 dots display for other refactoring suggestions that are relevant, and only turn off the complaint for rule TS2339: Property 'foo' does not exist on type 'bar'.


<EMAIL_ADDRESS>[no space after @] should error with a helpful hint

Describe the problem/challenge you have
users may accidentally forget to have a space in foo<EMAIL_ADDRESS>after @ and be confused why the data value is not showing up in the output.
(https://twitter.com/stylishandy/status/1455051198935957514?s=20)

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

I'm tempted to generalize this issue as, "Whenever there's an unrecognized annotation, ytt should error; in some set of common situations include a hint."
"Common Situations" could include:

#@load(...
<EMAIL_ADDRESS>(in general<EMAIL_ADDRESS>(e.g<EMAIL_ADDRESS>(in general<EMAIL_ADDRESS>(e.g. #@if, #@for, ...)

Where the hint could note the needed space:
ytt: Error: Overlaying data values (in following order: overlay.yml):
  Document on line overlay.yml:7:
    Map item (key 'foo') on line overlay.yml:9:
      Unknown annotation<EMAIL_ADDRESS>(did you mean '@ data...`, with a space after the '@'?)

i like where you going with it. this does make me think about backwards and forwards compatibility. do we get a benefit for being able to use unknown annotations today? (e.g. if some data values passed in i can use newer ytt functionality otherwise fall back? if we check annotations early enough this would become problematic...)

this does make me think about backwards and forwards compatibility.

Ditto.  I'm thinking of putting a feature flag on it (as in the user-facing feature flag). It would be more ytt-ish if we'd be stricter by default and be able to relax with the flag.
Something like... idonno... --ignore-unknown-annotations 😁 .

This idea was originally proposed in #114


Possible bug in bazel_features causing problem updating rules_jvm_external depndency

Not sure in which of two projects the problem is
https://github.com/bazel-contrib/rules_jvm_external/issues/1256
Updating rules_jvm_external to version 6.4 causes bazel_features error
can be reproduced on this project/branch
https://github.com/JetBrains/hirschgarten/pull/68
full error message:
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.
The following chain of repository dependencies lead to the missing definition.
 - @@bazel_features
This could either mean you have to add the '@@bazel_features' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
Computing main repo mapping:
ERROR: Error computing the main repository mapping: cycles detected during computation of main repo mapping

i tried fixing it by adding explicit dependency to bazel_features - but than i get another error:
ERROR: Failed to load Starlark extension '@@bazel_features_version//:version.bzl'.
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.
The following chain of repository dependencies lead to the missing definition.
 - @@bazel_features_version
This could either mean you have to add the '@@bazel_features_version' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
ERROR: Error computing the main repository mapping: cycles detected during computation of main repo mapping

Though, if I add bazel_features depndency explicit, but WORKSPACE-style - it starts to work. This might be a bug in bazel features so I'll file it there.

I'm pretty sure that the bug is in the transitively updated rules_java, which is used by Bazel's workspace suffix but doesn't properly declare the dep on bazel_features here: https://github.com/bazelbuild/rules_java/blob/master/java/repositories.bzl
@hvadehra

@daniel-b2c2 Yes, please do!

See https://github.com/bazelbuild/rules_java/issues/225#issuecomment-2388494967, a closer look revealed that this is an issue with rules_sonatype.


docs: Add support and build instructions and workflows for arm64

Is your feature request related to a problem? Please describe.
Now that arm64 architecture is official for lambdas, we should ensure Powertools works perfectly well and have a guide on how to take advantage of this feature via SAM and CDK.
Describe the solution you'd like
Update docs and test automation to include arm64
Describe alternatives you've considered

Additional context

Ref https://github.com/GrahamDumpleton/wrapt/issues/198 as pointed out by @eldritchideen, since we depend on X-Ray SDK this won't likely be possible with SAM CLI (maybe via Makefile but suboptimal), but a custom Lambda Layer.

I have also commented on what appears to be the root cause in the Pip builder that SAM uses to package the dependencies here. https://github.com/aws/aws-lambda-builders/issues/302
The wheel for wrapt gets built correctly, however as the file name has "linux" rather than "manylinux" it is rejected as not compatible.

This example repo shows how to work around the issue of Arm dependencies that require sdist builds with C extensions failing by packaging them in a layer.
https://github.com/eldritchideen/arm-python-lambda-example


Ignore query options from commented out queries

Fixes https://github.com/apache/pinot/issues/7714
Description
Since query option is processed as a regex, options are being picked up from commented-out queries. E.g.
SELECT * FROM table
-- SELECT * FROM table OPTION(...)

This change ensures that options in commented-out query are ignored.

Codecov Report

Merging #7869 (b9892a8) into master (0069fc3) will decrease coverage by 50.29%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master    #7869       +/-   ##
=============================================
- Coverage     64.84%   14.55%   -50.30%
+ Complexity     3379       80     -3299
=============================================
  Files          1508     1536       +28
  Lines         74883    79485     +4602
  Branches      10925    11926     +1001
=============================================
- Hits          48561    11566    -36995
- Misses        22857    67058    +44201
+ Partials       3465      861     -2604

Flag
Coverage Δ

integration1
?

integration2
?

unittests1
?

unittests2
14.55% <0.00%> (?)

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

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


Different result when running mk_prepare_ligand.py

Hi there,
I was trying to run mk_prepare_ligand.py to prepare ligand (sdf format to pdbqt format). I tried the exact same command (mk_prepare_ligand.py -i 1iep_ligand.sdf -o 1iep_ligand.pdbqt) for original 1iep_ligand.sdf provided in the Github page. However, I got different output than expected. Could you help me to figure it out?
p.s. left of the image is downloaded from Github, right hand side is my generated result.
Thanks in advance!

The current meeko version expects the input molecule to have explicit hydrogens and 3D coordinates, but earlier versions added hydrogens. Since the ligand SDF in the tutorial data folder is missing hydrogens, the prepared PDBQT misses all the "HD" atoms. We will need to add a check to bail out on molecules with implicit hydrogens, and update the tutorial.
The "REMARK SMILES" at the top of the PDBQT are for making an RDKit molecule with docked coordinates. AutoDock-GPU and Vina print these remarks to the output file, and meeko uses those lines to build the RDKit molecule from SMILES and assign the coordinates, using the Python API (example here) or the script mk_copy_coords.py.

Added check for implicit hydrogens: https://github.com/forlilab/Meeko/commit/05bdb0a1a1bf71ec82f59b9b1c25eaf7ad49e01b

Check for 3D coords in input mol to be added eventually: https://github.com/forlilab/Meeko/issues/25


Clock unstable during boot, tnCart stuck into boot loop

After reports of many users that latest tnCartWonder bitstreams were not booting into their MSXs when using WonderTANG! V2.0b boards (and strangely my Panasonic FS-A1WSX and Toshiba HX-10 were not affected, or at least rarely), I started troubleshooting the issue.
Users observed that their WonderTANG! V2.0b boards got stuck while booting, showing a continuous fast-blinking board led, and not progressing to the MSX boot screen (video was black).
I made a minimal tnCart configuration for my WonderTANG! V2.0b with the bare minimum to make it wondertang-compatible, i.e.:

use the current tnCart code, without tweaks (and without adding the i2s transmitter for the MAX98357A)
swap MSEL0 and MSEL1
add the required pin mappings for WonderTANG! V2.0b
leave the external and internal sound outputs unconnected

User pakoto from msx.org (thanks!) help me making tests remotely with his WonderTANG! V2.0b and his Panasonic FS-A1 (and a Sanyo MSX1) which he was reporting were failing 100% of the time.
Using that bare minimum setup we observed indeed the same boot loop with the fast-blinking board led.
I started suspecting that something was going on during the boot process, before freeing the MSX to boot.
I changed a bit the setup so that I could use the LED output for debugging some signals, connecting it to a logic analyzer.
I diagnosed the CLK_MEM_READY signal through the LED pin (IO 75) and saw that during all those failed boots, the CLK_MEM_READY was deasserted before the bootloader had time to complete, causing a RESET and provoking the boot loop.
I thought what change could have caused that problem, and remembered that in commit 62a343aea63ec7127754807950ec2bd71299bfeb "Fix #7 Synchronize the operating clock with the bus clock" you switched the clock for deriving the base clock for the fpga from the 27MHz clock of the Tang Nano 20k to the 3.58MHz of the cartridge clock.
To confirm if that was the issue, and without further analyzing the root cause of the clock not being stable for the whole bootloader phase, I did a quick test switching the base clock to the old 108MHz derived from the 27MHz Tang Nano 20k (just the CLK_MEM, without touching anything else for a quick test).
So basically commenting out this:
/*
    wire CLK_MEM_LOCK;
    assign CLK_MEM_READY = RESET_n && CLK_MEM_LOCK;
    rPLL u_pll_base (
        .CLKOUT(CLK_MEM),
        .LOCK(CLK_MEM_LOCK),
        .CLKOUTP(CLK_MEM_P),
        .CLKOUTD(),
        .CLKOUTD3(),
        .RESET(!RESET_n),
        .RESET_P(1'b0),
        .CLKIN(CLK_IN),
        .CLKFB(1'b0),
        .FBDSEL({1'b0,1'b0,1'b0,1'b0,1'b0,1'b0}),
        .IDSEL({1'b0,1'b0,1'b0,1'b0,1'b0,1'b0}),
        .ODSEL({1'b0,1'b0,1'b0,1'b0,1'b0,1'b0}),
        .PSDA({1'b0,1'b0,1'b0,1'b0}),
        .DUTYDA({1'b0,1'b0,1'b0,1'b0}),
        .FDLY({1'b1,1'b1,1'b1,1'b1})
    );

    defparam u_pll_base.FCLKIN = "3.58";
    defparam u_pll_base.DYN_IDIV_SEL = "false";
    defparam u_pll_base.IDIV_SEL = 0;
    defparam u_pll_base.DYN_FBDIV_SEL = "false";
    defparam u_pll_base.FBDIV_SEL = 29;
    defparam u_pll_base.DYN_ODIV_SEL = "false";
    defparam u_pll_base.ODIV_SEL = 8;
    defparam u_pll_base.PSDA_SEL = "1000";
    defparam u_pll_base.DYN_DA_EN = "false";
    defparam u_pll_base.DUTYDA_SEL = "1000";
    defparam u_pll_base.CLKOUT_FT_DIR = 1'b1;
    defparam u_pll_base.CLKOUTP_FT_DIR = 1'b1;
    defparam u_pll_base.CLKOUT_DLY_STEP = 0;
    defparam u_pll_base.CLKOUTP_DLY_STEP = 0;
    defparam u_pll_base.CLKFB_SEL = "internal";
    defparam u_pll_base.CLKOUT_BYPASS = "false";
    defparam u_pll_base.CLKOUTP_BYPASS = "false";
    defparam u_pll_base.CLKOUTD_BYPASS = "false";
    defparam u_pll_base.DYN_SDIV_SEL = 2;
    defparam u_pll_base.CLKOUTD_SRC = "CLKOUT";
    defparam u_pll_base.CLKOUTD3_SRC = "CLKOUT";
    defparam u_pll_base.DEVICE = "GW2AR-18C";
*/

and adding this:
    wire CLK_MEM_LOCK;
    assign CLK_MEM_READY = RESET_n && CLK_MEM_LOCK;
    localparam FREQ=108_000;
    rPLL u_pll_base (
        .CLKOUT(CLK_MEM),
        .LOCK(CLK_MEM_LOCK),
        .CLKOUTP(CLK_MEM_P),
        .CLKOUTD(),
        .CLKOUTD3(),
        .RESET(!RESET_n),
        .RESET_P(1'b0),
        .CLKIN(CLK_27M),
        .CLKFB(1'b0),
        .FBDSEL(6'b000000),
        .IDSEL(6'b000000),
        .ODSEL(6'b000000),
        .PSDA(4'b0000),
        .DUTYDA(4'b0000),
        .FDLY(4'b1111)
    );
    defparam u_pll_base.FCLKIN = "27";
    defparam u_pll_base.DYN_IDIV_SEL = "false";
    defparam u_pll_base.IDIV_SEL = 0;
    defparam u_pll_base.DYN_FBDIV_SEL = "false";
    defparam u_pll_base.FBDIV_SEL = 3;
    defparam u_pll_base.DYN_ODIV_SEL = "false";
    defparam u_pll_base.ODIV_SEL = 8;
    defparam u_pll_base.PSDA_SEL = "1000";
    defparam u_pll_base.DYN_DA_EN = "false";
    defparam u_pll_base.DUTYDA_SEL = "1000";
    defparam u_pll_base.CLKOUT_FT_DIR = 1'b1;
    defparam u_pll_base.CLKOUTP_FT_DIR = 1'b1;
    defparam u_pll_base.CLKOUT_DLY_STEP = 0;
    defparam u_pll_base.CLKOUTP_DLY_STEP = 0;
    defparam u_pll_base.CLKFB_SEL = "internal";
    defparam u_pll_base.CLKOUT_BYPASS = "false";
    defparam u_pll_base.CLKOUTP_BYPASS = "false";
    defparam u_pll_base.CLKOUTD_BYPASS = "false";
    defparam u_pll_base.DYN_SDIV_SEL = 2;
    defparam u_pll_base.CLKOUTD_SRC = "CLKOUT";
    defparam u_pll_base.CLKOUTD3_SRC = "CLKOUT";
    defparam u_pll_base.DEVICE = "GW2AR-18C";

After that change, the WonderTANG! V2.0 of user pakoto started to boot 100% reliably in his Panasonic FS-A1 and Sanyo MSX1 without getting into the boot loop anymore (something that never happened before).
So, there is clearly a problem when using the CART_CLK, as at least in some MSX, the clock is not stable (and becomes not ready) in the middle of the bootloader process.
As I said, I didn't further analyze the root cause of it, but maybe it could be related to the following: as the CART_CLK comes from the CPU clock and the CPU clock comes from the VDP clock, maybe the fact that SYSRESET is help during bootloader causes the VDP to stop providing a clock. On some MSX that happens before than others, letting some of them complete the bootloader (and get to boot the MSX system) and others to get stuck into the dreaded boot loop.
And that explains too why when using the 27MHz clock to derive the base clock, the bootlopp never happens.
Of course, changing the clock that way was just to confirm the issue, and it is NOT a proposed solution as that change has other implications, and you made that change to fix other issues.
So something needs to be thought to fix the problem the right way.
Looking forward for your comments.

Thanks for investigating this issue.
You have identified the following issues

PLL lock is removed when cartridge clock is used.
PLL lock is removed and SDRAM module is reset.
SDRAM module resets, other modules also reset
The BOOTLOADER module is repeatedly run, causing the LEDs to blink repeatedly.
WAITn is still asserted and MSX will not boot (video was black)

What causes the clock signal to be unstable?
You mentioned that the VDP clock may be stopped, but why is it repeating?
Will the power supply voltage fluctuate due to changes in load, causing unstable oscillation?
About the problem when using with onboard 27MHz
Dot clock is generated in sync with 3.58MHz, causing jitter in the DVI output of the V9990 emulation, resulting in DVI devices that cannot be supported
If the SYNC_CLK_EN parameter of the UMA module is set to 0, the module will operate asynchronously and the DIV output will be stable.
However, I do not know how 4MB RAM, Nextor, and FM-BIOS will work under these conditions.
Countermeasure
I think there are two means.

Use onboard 27MHz.
After the PLL locks, do not reset even if the lock is released

I quickly checked.
If I generate the base clock at 27MHz and set SYNC_CLK_EN to 0, I can start up on FS-A1F, but 1chip MSX hangs up while starting NEXTOR.

You mentioned that the VDP clock may be stopped, but why is it repeating? Will the power supply voltage fluctuate due to changes in load, causing unstable oscillation?

That was a simply a wild guess with no actual check.
Either the clock is stopping (and restarting, otherwise the bootloader would not loop) or the clock is glitching enough for the pll to loose sync.
I don't think the power supply is specifically involved, as there were reports from very different machines (with linear and switched power supplies).
I took a quick look at the manual for V9958 (which is the VDP present on my Omega and Panasonic A1-WSX) to check what should be the behavior of CPUCLK when the V9958 chip RESET_n signal is low, but couldn't find any information (SYS_RESET_n is kept low until the BOOTLOADER completes).
Maybe the CPUCLK is not guaranteed to work flawlessly until RESET_n is high.
This should be further investigated.
Thanks.

Eventually, once the reset on the MSX side is released and the clock is stable, the PLL should remain locked.
But why is the output clock forever unstable?
Due to the specifications of the cartridge bus, it is not possible to send a reset signal from the cartridge side to the MSX.
So the SYS_RESET_n signal is used internally by the FPGA and does not affect the reset on the MSX side.
(The reason why the screen remains black is due to the WAIT signal, not the RESET signal)

Oh, you are completely right. I forgot for a moment that the cartridge reset signal is an input signal from the tnCart point of view... So the cpu clock from the vdp should be running continuously.
Then I wonder if those clock glitches do happen too outside of the bootloader phase (and if not why only on the bootloader phase).
In the bootloader phase they cause a direct reset of the bootloader.
But outside the bootloader phase (when BOOT_n is 1) they should also cause a reset of the SDRAM module (via CLK_MEM_READY which depends on the pll lock) and most of the modules (via RESET_n which depends on CLK_BASE_READY which depends on the pll lock).
Isn't it?

Does the cartridge reboot when the boot loader is running or when it completes?
If this issue occurs after the bootloader completes, the following possibilities exist:
Accessing SDRAM in the FPGA from MSX generates a lot of noise. Isn't it possible that that noise gets mixed into the clock signal and causes the PLL to unlock?
Once the tnCart bootloader is complete, the MSX BIOS will begin searching for RAM. This creates a lot of noise on the power line.
(I checked the 5V pin on the tnCart board with an oscilloscope. However, I don't know if there is a similar phenomenon with the WonderTANG board.)
If this is the cause, it cannot be fixed within the FPGA, so the only option is to use the 27MHz onboard clock.

I made the following test.
I modified the fpga code to use again the 3.58MHz clock but this time considering the BASE clock ready when at least the PLL has locked once.
    /***************************************************************
     * 3.58MHz * 30 = 107.4MHz
     ***************************************************************/
    wire CLK_MEM_LOCK;
    logic CLK_MEM_LOCK_ONCE = 1'b0;
    always_ff @(posedge CLK_MEM_LOCK) begin
        CLK_MEM_LOCK_ONCE = 1'b1;
    end
    assign CLK_MEM_READY = RESET_n && CLK_MEM_LOCK_ONCE;
    rPLL u_pll_base (
        .CLKOUT(CLK_MEM),
        .LOCK(CLK_MEM_LOCK),
        .CLKOUTP(CLK_MEM_P),
        .CLKOUTD(),
        .CLKOUTD3(),
        .RESET(!RESET_n),
        .RESET_P(1'b0),
        .CLKIN(CLK_IN),
        .CLKFB(1'b0),
        .FBDSEL({1'b0,1'b0,1'b0,1'b0,1'b0,1'b0}),
        .IDSEL({1'b0,1'b0,1'b0,1'b0,1'b0,1'b0}),
        .ODSEL({1'b0,1'b0,1'b0,1'b0,1'b0,1'b0}),
        .PSDA({1'b0,1'b0,1'b0,1'b0}),
        .DUTYDA({1'b0,1'b0,1'b0,1'b0}),
        .FDLY({1'b1,1'b1,1'b1,1'b1})
    );

    defparam u_pll_base.FCLKIN = "3.58";
    defparam u_pll_base.DYN_IDIV_SEL = "false";
    defparam u_pll_base.IDIV_SEL = 0;
    defparam u_pll_base.DYN_FBDIV_SEL = "false";
    defparam u_pll_base.FBDIV_SEL = 29;
    defparam u_pll_base.DYN_ODIV_SEL = "false";
    defparam u_pll_base.ODIV_SEL = 8;
    defparam u_pll_base.PSDA_SEL = "1000";
    defparam u_pll_base.DYN_DA_EN = "false";
    defparam u_pll_base.DUTYDA_SEL = "1000";
    defparam u_pll_base.CLKOUT_FT_DIR = 1'b1;
    defparam u_pll_base.CLKOUTP_FT_DIR = 1'b1;
    defparam u_pll_base.CLKOUT_DLY_STEP = 0;
    defparam u_pll_base.CLKOUTP_DLY_STEP = 0;
    defparam u_pll_base.CLKFB_SEL = "internal";
    defparam u_pll_base.CLKOUT_BYPASS = "false";
    defparam u_pll_base.CLKOUTP_BYPASS = "false";
    defparam u_pll_base.CLKOUTD_BYPASS = "false";
    defparam u_pll_base.DYN_SDIV_SEL = 2;
    defparam u_pll_base.CLKOUTD_SRC = "CLKOUT";
    defparam u_pll_base.CLKOUTD3_SRC = "CLKOUT";
    defparam u_pll_base.DEVICE = "GW2AR-18C";

I also used the board LED to signal if the bootloader has started or ended, and once ended, if it was executed again.
The LED ignores anything related to LedBoot or LedNextor, and lights only according to LedDebug. It should briefly turn on when the MSX powers on, then off when the bootloader finishes, and remain on again in case the bootloader is restarted at least once.
    BOOTLOADER #(
        .XFER_SRC_ADDR  (CONFIG::FLASH_ADDR_BIOS),
        .XFER_DST_ADDR  (CONFIG::RAM_ADDR_BIOS),
        .XFER_SIZE      (CONFIG::FLASH_SIZE_BIOS),
        .MEGAROM_CLEAR_ADDR(CONFIG::RAM_ADDR_MEGAROM),
        .MEGAROM_CLEAR_SIZE(32768),
        .RAM_CLEAR_ADDR (CONFIG::RAM_ADDR_RAM),
        .RAM_CLEAR_SIZE (65536)
    ) u_boot (
        .RESET_n,
        .CLK,
        .Flash,
        .Ram            (ExpRam[RAM_BOOTLOADER]),
        .Led            (LedBoot),
        .ClearMegarom   (1'b1),
        .READY          (BOOT_n)
    );

    logic [1:0] state = 0;
    always_ff @(posedge CLK) begin
        case(state)
            default: begin
                LedDebug.State <= LedDebug.LED_STATE_ON;
                if (BOOT_n) state <= 2'd1;
            end
            2'd1: begin
                LedDebug.State <= LedDebug.LED_STATE_OFF;
                if (!BOOT_n) state <= 2'd2;
            end
            2'd2: begin
                LedDebug.State <= LedDebug.LED_STATE_ON;
            end
        endcase
    end

I did many tests and that's what I found (remember with the 3.58MHz clock as reference):

the boot fails a large percentage of the tries, without progressing to the end of the bootloader (so even if we consider artificially stable the clock, by ignoring the actual PLL locking if at least it has locked once, the fact that the clock is unstable makes the boot unstable)
sometimes the boot completes correctly
if the bootloader completes, it is never restarted and no problems are experienced (I even did a really long Space Manbow run after one of the successful boots...)

So, answering your question, according to my tests, the PLL unlocks randomly only during the bootloader phase.
So it seems that we can't reliably use the 3.58MHz clock during the bootloader phase, but for some reason, it works fine after that and we can use it then.

BOOT_n transitions from 0 to 1 and then returns to 0 (check with LED)
CLK_MEM_LOCK_ONCE changes from 0 to 1 and does not return to 0 (Probably so)
CLK_MEM_READY also changes from 0 to 1 and does not return to 0
The value of u_boot.RESET_n is unconfirmed.

u_boot.RESET_n is the same as RESET_n in the TOP module, and is generated in the section below.
When CLK_BASE_READY and sdram_ready both become 1, RESET_n also becomes 1.
        reg reset_n = 0;
        assign RESET_n = reset_n;
        always_ff @(posedge CLK_BASE or negedge CLK_BASE_READY or negedge sdram_ready) begin
            if(!CLK_BASE_READY) reset_n <= 0;       // PLL 準備中ならリセット
            else if(!sdram_ready) reset_n <= 0;     // SDRAM 準備中ならリセット
            else reset_n <= 1;
        end

CLK_BASE_READY is the same as CLK_MEM_READY, so it should go from 0 to 1 and not return to 0 (Probably so)
The value of sdram_ready is unconfirmed.

The READY signal generation for the SDRAM module is as follows: READY will not become 0 unless RESET_n (same as CLK_BASE_READY) becomes 0.
Considering that, wouldn't sdram_ready also remain at 1 after going from 0 to 1?
    always_ff @(posedge CLK or negedge RESET_n)
    begin
        if(!RESET_n)                 READY <= 0;
        else if(state == STATE_IDLE) READY <= 1;
    end

Is something happening somewhere other than what is described in the source?
Are the SETUP time and HOLD time of registers such as READY signal and RESET signal within the specified range?

The Timing Analysis Report is clean (no red lines), but the report assumes the clock is working correctly.
So maybe due to the clock instability those SETUP and HOLD times are not completely met in the real world.

I changed tnCartWonder to use 3.58Mhz(defined XXX_TEMP_FIX_MUST_BE_FIXED_IN_A_PROPER_WAY_WONT_PASS_TIMING_REPORT_AND_MAY_CAUSE_INSTABILITIES) and looked at the post-synthesis list and found that BOOT_n was dependent on the state of the LED module.
It seems that tnCart 3.58MHz and tnCartWonder 27MHz give correct synthesis results.
It is unclear why this result occurs.
tnCartWonder3.58Mhz synthesis result
LUT3 n199_s3 (	// wire n199_7 = blink_cout[2:0] == 3'b111;
    .F(n199_7),
    .I0(blink_count[0]),
    .I1(blink_count[1]),
    .I2(blink_count[2])
);
defparam n199_s3.INIT=8'h80;

LUT4 n198_s3 (	// wire n198_7 = blink_count[3:0] == 4'b1111;
    .F(n198_7),
    .I0(blink_count[0]),
    .I1(blink_count[1]),
    .I2(blink_count[2]),
    .I3(blink_count[3])
);
defparam n198_s3.INIT=16'h8000;

LUT4 n202_s7 (	// wire n202_11 = blink_count[22:19] == 4'b1111;
    .F(n202_11),
    .I0(blink_count[19]),
    .I1(blink_count[21]),
    .I2(blink_count[20]),
    .I3(blink_count[22])
);
defparam n202_s7.INIT=16'h1000;

LUT4 n202_s8 (	// wire n202_12 = blink_count[14:13] == 2'b11 & blink_count[18] & blink_count[16];
    .F(n202_12),
    .I0(blink_count[16]),
    .I1(blink_count[18]),
    .I2(blink_count[13]),
    .I3(blink_count[14])
);
defparam n202_s8.INIT=16'h1000;

LUT4 n202_s9 (	// wire n202_13 = blink_count[10] & !blink_count[12] & !blink_count[11] & !blink_count[9];
    .F(n202_13),
    .I0(blink_count[9]),
    .I1(blink_count[11]),
    .I2(blink_count[12]),
    .I3(blink_count[10])
);
defparam n202_s9.INIT=16'h0100;

LUT3 n196_s3 (	// wire n196_7 = blink[5:4] == 2'b11 & n198_7;
    .F(n196_7),
    .I0(blink_count[4]),
    .I1(blink_count[5]),
    .I2(n198_7)
);
defparam n196_s3.INIT=8'h80;

LUT4 n202_s5 (	// wire n202_9 = {blink_count[17], n202_11, blink_count[15], blink_count[6]} == 4'b1100;
    .F(n202_9),
    .I0(blink_count[6]),
    .I1(blink_count[15]),
    .I2(n202_11),
    .I3(blink_count[17])
);
defparam n202_s5.INIT=16'h1000;

LUT4 n202_s6 (	// wire n202_10 = n202_13 & blink_count[8] & blink_count[7] & n202_12;
    .F(n202_10),
    .I0(n202_12),
    .I1(blink_count[7]),
    .I2(blink_count[8]),
    .I3(n202_13)
);
defparam n202_s6.INIT=16'h8000;

LUT4 n202_s4 (	//
    .F(n202_8),
    .I0(n196_7),
    .I1(n202_9),
    .I2(n202_10),
    .I3(\LedBoot.State [0])
);
defparam n202_s4.INIT=16'h7F00;

LUT3 n199_s2 (	// wire n199_6 = n202_8 & (n199_7 ^ blink_count[3]);
    .F(n199_6),
    .I0(n199_7),
    .I1(blink_count[3]),
    .I2(n202_8)
);
defparam n199_s2.INIT=8'h60;

DFFCE READY_s0 (	// always_ff @(posedge CLK_BASE or negedge n119_6) if(n119_6) BOOT_n <= 0; else if(CE) BOOT_n <= VCC;
    .Q(BOOT_n),
    .D(VCC),
    .CLK(CLK_BASE),
    .CE(n189_10),
    .CLEAR(n119_6)
);

tnCartWonder27Mhz synthesis result
rPLL u_pll_base (
    .CLKOUT(CLK_BASE),
    .CLKOUTP(O_sdram_clk_d),
    .CLKOUTD(u_pll_base_3_CLKOUTD),
    .CLKOUTD3(u_pll_base_3_CLKOUTD3),
    .LOCK(CLK_MEM_LOCK),
    .CLKIN(CLK_27M_d),
    .CLKFB(GND),
    .FBDSEL({GND,GND,GND,GND,GND,GND}),
    .IDSEL({GND,GND,GND,GND,GND,GND}),
    .ODSEL({GND,GND,GND,GND,GND,GND}),
    .DUTYDA({GND,GND,GND,GND}),
    .PSDA({GND,GND,GND,GND}),
    .FDLY({VCC,VCC,VCC,VCC}),
    .RESET(GND),
    .RESET_P(GND)
);

INV n12_s2 (
    .O(n12_6),
    .I(CLK_MEM_LOCK)
);

LUT4 \Ram.TIMING_s  (	// \Ram.TIMING = state[2:0] == 8;
    .F(\Ram.TIMING ),
    .I0(state[0]),
    .I1(state[1]),
    .I2(state[2]),
    .I3(\Ram.TIMING_3 )
);
defparam \Ram.TIMING_s .INIT=16'h0100;

DFFCE READY_s0 (
    .Q(sdram_ready),
    .D(VCC),
    .CLK(CLK_BASE),
    .CE(\Ram.TIMING ),
    .CLEAR(n12_6)
);

LUT2 n35_s0 (	// n35_4 = sdram_ready & CLK_MEM_LOCK;
    .F(n35_4),
    .I0(sdram_ready),
    .I1(CLK_MEM_LOCK)
);
defparam n35_s0.INIT=4'h7;

DFFC reset_n_s0 (
    .Q(DAC_SDMODE_n_d),
    .D(VCC),
    .CLK(CLK_BASE),
    .CLEAR(n35_4)
);

INV n119_s2 (
    .O(n119_6),
    .I(DAC_SDMODE_n_d)
);

DFFCE READ_s0 (
    .Q(BOOT_n),
    .D(VCC),
    .CLK(CLK_BASE),
    .CE(n189_10),
    .CLEAR(n119_6)
);

tnCart3.58Mhz synthesis result
rPLL u_pll_base (
    .CLKOUT(CLK_BASE),
    .CLKOUTP(O_sdram_clk_d),
    .CLKOUTD(u_pll_base_3_CLKOUTD),
    .CLKOUTD3(u_pll_base_3_CLKOUTD3),
    .LOCK(CLK_MEM_LOCK),
    .CLKIN(CART_CLOCK_d),
    .CLKFB(GND),
    .FBDSEL({GND,GND,GND,GND,GND,GND}),
    .IDSEL({GND,GND,GND,GND,GND,GND}),
    .ODSEL({GND,GND,GND,GND,GND,GND}),
    .DUTYDA({GND,GND,GND,GND}),
    .PSDA({GND,GND,GND,GND}),
    .FDLY({VCC,VCC,VCC,VCC}),
    .RESET(GND),
    .RESET_P(GND)
);

INV n12_s2 (
    .O(n12_6),
    .I(CLK_MEM_LOCK)
);

DFFCE READY_s0 (
    .Q(sdram_ready),
    .D(VCC),
    .CLK(CLK_BASE),
    .CE(\Ram.TIMING ),
    .CLEAR(n12_6)
);

LUT2 n34_s0 (
    .F(n34_4),
    .I0(sdram_ready),
    .I1(CLK_MEM_LOCK)
);

DFFC reset_n_s0 (
    .Q(reset_n),
    .D(VCC),
    .CLK(CLK_BASE),
    .CLEAR(n34_4)
);

INV n414_s2 (
    .O(n414_6),
    .I(reset_n)
);

DFFCE READY_s0 (
    .Q(BOOT_n),
    .D(VCC),
    .CLK(CLK_BASE),
    .CE(n189_10),
    .CLEAR(n414_6)
);

I think it's a bug in the gowin synthesizer.
DAC_SDMODE_n may be the cause, so I fixed it as follows.
This resulted in a synthesis result independent of the LED module.
I'm not sure if this is the cause of the bootloop, so please check.
    assign DAC_SDMODE_n = RESET_n;

↓
    reg ff_dac_rst;
    assign DAC_SDMODE_n = ff_dac_rst;
    always_ff @(posedge CLK_DAC) ff_dac_rst <= RESET_n;

I just tested the proposed fix, but the boot loop continues.
diff --git a/rtl/src/board/wondertang_rev200b/wondertang_board_rev200b_clock.sv b/rtl/src/board/wondertang_rev200b/wondertang_board_rev200b_clock.sv
index 72b457c..2612fbe 100644
--- a/rtl/src/board/wondertang_rev200b/wondertang_board_rev200b_clock.sv
+++ b/rtl/src/board/wondertang_rev200b/wondertang_board_rev200b_clock.sv
@@ -121,7 +121,7 @@ module WONDERTANG_BOARD_REV200B_CLOCK (
     defparam u_div_tmds.DIV_MODE = "5";
     defparam u_div_tmds.GSREN = "false";

-`ifdef XXX_TEMP_FIX_MUST_BE_FIXED_IN_A_PROPER_WAY_WONT_PASS_TIMING_REPORT_AND_MAY_CAUSE_INSTABILITIES
+`ifndef XXX_TEMP_FIX_MUST_BE_FIXED_IN_A_PROPER_WAY_WONT_PASS_TIMING_REPORT_AND_MAY_CAUSE_INSTABILITIES
     /***************************************************************
      * 3.58MHz * 30 = 107.4MHz
      ***************************************************************/
diff --git a/rtl/src/wondertang_board_rev200b_top.sv b/rtl/src/wondertang_board_rev200b_top.sv
index a94969d..a85d3d9 100644
--- a/rtl/src/wondertang_board_rev200b_top.sv
+++ b/rtl/src/wondertang_board_rev200b_top.sv
@@ -434,7 +434,10 @@ module WONDERTANG_BOARD_REV200B_TOP (
     SOUND_IF SoundInternal();

     // unmute the DAC
-    assign DAC_SDMODE_n = RESET_n;
+//    assign DAC_SDMODE_n = RESET_n;
+    reg ff_dac_rst;
+    assign DAC_SDMODE_n = ff_dac_rst;
+    always_ff @(posedge CLK_DAC) ff_dac_rst <= RESET_n;

     /***************************************************************
      * VIDEO

I reverted the define to go back to the 27MHz clock but leaving new DAC_SDMODE_n non-combinatorial assignment, and the boot loop goes away as on the original temp fix:
diff --git a/rtl/src/wondertang_board_rev200b_top.sv b/rtl/src/wondertang_board_rev200b_top.sv
index a94969d..a85d3d9 100644
--- a/rtl/src/wondertang_board_rev200b_top.sv
+++ b/rtl/src/wondertang_board_rev200b_top.sv
@@ -434,7 +434,10 @@ module WONDERTANG_BOARD_REV200B_TOP (
     SOUND_IF SoundInternal();

     // unmute the DAC
-    assign DAC_SDMODE_n = RESET_n;
+//    assign DAC_SDMODE_n = RESET_n;
+    reg ff_dac_rst;
+    assign DAC_SDMODE_n = ff_dac_rst;
+    always_ff @(posedge CLK_DAC) ff_dac_rst <= RESET_n;

     /***************************************************************
      * VIDEO

By the way, I just verified that the bootloop problem is not specific of the WonderTANG! V2.0b board, but it is also present in WonderTANG! V1.02d and WonderTANG! V1.01c boards.
And in WonderTANG! V1.02d the only difference is the swap of MSEL0 and MSEL1.
I think that the fact that DAC_SDMODE_n appears in the 27MHz tnCartWoder synthesis is just because it is combinatorially assigned to RESET_n, and then the synthesis tool may have replaced RESET_n by DAC_SDMODE_n with the same outcome.
The strange thing is the synthesis output you posted on the 3.58MHz tnCartWonder, where the RESET_n has been replaced by some expression depending on the blink count of the LED...

I just did another test.
I commented out the current LED code (so that the synthesis tool can't generate that weird output you showed), and replaced it with code to just turn on the LED when the TF Card is accessed (i.e. when LedNextor turns it on).
But the bootloop is still there when using the 3.58MHz clock (and gets fixed as soon as switching to the 27MHz clock).
diff --git a/rtl/src/peripheral/led.sv b/rtl/src/peripheral/led.sv
index 7f22f77..ea9f140 100644
--- a/rtl/src/peripheral/led.sv
+++ b/rtl/src/peripheral/led.sv
@@ -73,6 +73,7 @@ module LED #(
     output  reg     LedPort             // LED ポート
 );

+`ifdef COMMENT_OUT
     /***************************************************************
      * ディレイカウンタ
      ***************************************************************/
@@ -125,6 +126,10 @@ module LED #(
             LedPort <= (delay_count != 0) ? 1'b1 : 1'b0;
         end
     end
+`else
+    always_ff @(posedge CLK)
+        LedPort <= (LedNextor.State == LedNextor.LED_STATE_ON);
+`endif

 endmodule

When I checked again, I couldn't get any results that depended on the LED module, so I think it was a misunderstanding.

Since this problem cannot be resolved immediately, onboard 27 MHz will be used until the cause is identified.
Continue to investigate the cause of the problem, as it is not a root cause resolution.

I have observed a noise in the 3.58 MHz clock and a reboot of the boot loader. However, I do not know if this is the cause of the repeat.

The CART_CLOCK noise was reproducible and occurred immediately after the V9990 video output started.
However, it no longer occurs after cleaning the card edge terminals.
Did the buffer IC become unstable due to fluctuations in current consumption?

The CART_CLOCK noise was reproducible and occurred immediately after the V9990 video output started. However, it no longer occurs after cleaning the card edge terminals. Did the buffer IC become unstable due to fluctuations in current consumption?

Note that in my original tests, the V9990 was not even enabled (to simplify things and reduce rtl build times for tests).
Do you have reproduced the boot loop on you tnCart (not WonderTANG!) boards?

I have tested the tncart on PCB 2.0 on a Philips VG8020 and it gets stuck when starting nextor.sys and a led on the tang lights up. Is there a solution? Thanks.

That description seems to be unrelated to this specific issue.
It should be better that you open a specific issue for the WonderTANG using the tnCart rtl on a Philips VG8020.
Also note that WonderTANG 2.0 is currently not supported by the tnCart github project (it is "supported" in tnCartWonder though), so you should first make sure that any issue with WonderTANG 2.0 can be reproduced also with WonderTANG 1.01c or 1.02d to get support here.

The CART_CLOCK noise was reproducible and occurred immediately after the V9990 video output started. However, it no longer occurs after cleaning the card edge terminals. Did the buffer IC become unstable due to fluctuations in current consumption?

Note that in my original tests, the V9990 was not even enabled (to simplify things and reduce rtl build times for tests).
Do you have reproduced the boot loop on your tnCart (not WonderTANG!) boards?

The tnCart board has not had a bootloop problem yet so far.

Do you have reproduced the boot loop on your tnCart (not WonderTANG!) boards?

The tnCart board has not had a bootloop problem yet so far.

Great.
Do you think that rev2 is ready to be built? Or it still requires some updates/fixes? I would build a tnCart board to compare with WonderTANG! if it is considered ok to get built in its current status.
Do you plan to publish the complete rev2 kicad design files, besides the schematic?
Thanks!

Great. Do you think that rev2 is ready to be built? Or it still requires some updates/fixes? I would build a tnCart board to compare with WonderTANG! if it is considered ok to get built in its current status. Do you plan to publish the complete rev2 kicad design files, besides the schematic?

Sorry, work has been busy and no progress has been made on the rev2 board.
I am reconsidering whether an I2S DAC is more advantageous in terms of cost and board space occupied than a PDM + active filter.

Sorry, work has been busy and no progress has been made on the rev2 board. I am reconsidering whether an I2S DAC is more advantageous in terms of cost and board space occupied than a PDM + active filter.

Thanks for your feedback.
Yes, there are lots of cheap I2S DAC modules out there. Using one of those would be cheaper (and easier to solder for hobbyists) than sourcing specific components for the active filter (if it is not a trivial one).

I quickly checked. If I generate the base clock at 27MHz and set SYNC_CLK_EN to 0, I can start up on FS-A1F, but 1chip MSX hangs up while starting NEXTOR.

If the freezing problem with 1chip MSX has been resolved? Still got the same issue on fpga based clones.

I quickly checked. If I generate the base clock at 27MHz and set SYNC_CLK_EN to 0, I can start up on FS-A1F, but 1chip MSX hangs up while starting NEXTOR.

If the freezing problem with 1chip MSX has been resolved? Still got the same issue on fpga based clones.

Since bus timing on the T80 is more severe than on the Z80, it is imperative that memory access timing be synchronized with the clock.

I quickly checked. If I generate the base clock at 27MHz and set SYNC_CLK_EN to 0, I can start up on FS-A1F, but 1chip MSX hangs up while starting NEXTOR.

If the freezing problem with 1chip MSX has been resolved? Still got the same issue on fpga based clones.

Will Nextor work on this branch?
tnCart-develop-new-uma-timing

I quickly checked. If I generate the base clock at 27MHz and set SYNC_CLK_EN to 0, I can start up on FS-A1F, but 1chip MSX hangs up while starting NEXTOR.

If the freezing problem with 1chip MSX has been resolved? Still got the same issue on fpga based clones.

Will Nextor work on this branch?
tnCart-develop-new-uma-timing

Yes, it works!
Thanks.
I'll try to check things out after the holidays.
HNY!


Add kubeseal

https://github.com/aquaproj/aqua-registry/issues/858

Duplicated https://github.com/aquaproj/aqua-registry/issues/876


⚠ Bofrost.de has degraded performance

In d9b140a, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1029 ms

Resolved: Bofrost.de performance has improved in 251728d.


Disable confirmation after take photo

hi , is there are way to disable "use photo" & "retake" option and immediately return the result?

Sorry, but it is not clear what your question is. Could you please provide more details?
I will close the issue until new details are available.

hi, i have other issue i cant start the preview, it shows nothing.
i set the builder as in your tutorial
fotoapparat = Fotoapparat.with(this)
.into(cameraView)
.previewScaleType(ScaleType.CENTER_CROP)
.lensPosition(LensPositionSelectors.back())
.previewSize(SizeSelectors.biggestSize())
.photoSize(SizeSelectors.biggestSize())
.build();
@Override
protected void onStart() {
super.onStart();
    fotoapparat.start();
}

Make sure that you have the camera permission


ADR037 Review apps architecture

PR Checklist

[ ] If you are proposing a new decision record document, used the right template for that
- (ADR, decision-record, engagement, research)
[ ] Set yourself as the Assignee
[ ] Tag anyone you would like to review, or @forms-design or @forms-devs
[ ] Fill in the template below

What
Adds ADR037 for the architecture of GOV.UK Forms review apps
Read it formatted
How to review
Read it, think about it, discuss.
Who can review
@alphagov/forms-infrastructure @james-sheppard-gov-uk @chao-xian

is this an oversight or a deliberate decision to reduce scope at this point?

Yes, this is about reducing scope on the first pass. I will clarify that in the text too.

Nice 🙌 , this sounds like a good way forward, thank you!


Deduplication in StoreAPI

Currently deduplication is done in the querier, at the Select stage. This means Store API gRPC queries, even going via query do not get deduplication. For thanos-remote-read this means it does not get deduplication via querier.
Add a store API request option to ask for deduplication.
This could be useful for other purposes, e.g. it would be possible to push deduplication down to a child query node, to avoid sending extra data over the network (likely would need to be optional, even if #2699 made it possible to do this in a streaming way this would mean decoding chunks twice).

@bwplotka Is this fixed by https://github.com/thanos-io/thanos/pull/2711?

No, we dedup the duplicated chunks yes, but only if the series is duplicated without "replica label removing" phase. This ticket is about doing the replica rem phase and some kind of initial dedup on Store API.
I think it would be a solid request, except that it will be highly expensive. This is because for true deduplication you have decode chunks and encode them again (because StoreAPI exposes chunks). On Querier, however, PromQL operates on samples so we decode + duplicate in one go, there is little overhead. This is something to be aware of here.
There is option C, where we could do partial deduplication, so we could remove labels and merge chunks without encoding/decoding in a way that: For 1:1 dups we kill dups, for time overlapping chunks that are not identical we just pass them through. Querier sorts chunks and deduplicates them anyway, so that could work. Still, for Prometheus replicas, it's not very helpful - chunks are rather never identical due to scrape interval randomness.
So.. at then end, I don't really see much value. I think we should rather port deduplication to thanos-remote-read for now, WDYT? @dgl

I agree doing deduplication in thanos-remote-read makes sense if there's not really a use case elsewhere. The attraction for me is the code for deduplication isn't currently a public API, but I'm sure I can work something out.
(I still think there are cases where being able to push some of the querier work to other places has value but I suspect it's not a priority right now as there's plenty of more important things to work on. e.g. It might be useful for a custom store API server to know that deduplication is happening or not to optimise its responses.)


3D segmentation

Thank you for your interesting work.
Is there a 3D implementation for medical image segmentation like .nifti images?
Thanks!

Hi @RRouhi, this implementation only includes a 2D Swin implementation. I would recommend checking out this paper and this repo. I hope this helps!

Thank you!
I cannot see the code at the link provided :
https://github.com/Project-MONAI/research-contributions


Add Unit Tests for sicd_elements.blocks

Apologies @Darder for the large PR
Add additional unit tests for the sicd_elements module, specifically blocks.py
This PR:

New tests in test_sicd_elements_blocks.py
Minor cleanup in blocks.py

Details + Before/After coverage report
Coverage from main branch:
pytest tests --cov=sarpy.io.complex.sicd_elements.blocks --cov-report term-missing

Name
Stmts
Miss
Cover
Missing

sarpy/io/complex/sicd_elements/blocks.py
644
222
66%
96, 99, 101, 178, 195-201, 220-232, 285, 288, 290, 318-322, 338-344, 400, 416-422, 472, 475, 477, 507-512, 533-539, 596, 599, 601, 660-666, 696-701, 721-727, 795-801, 856-862, 892, 894, 926, 932, 935, 939, 960, 963, 1040-1055, 1073, 1091, 1108, 1116, 1144-1155, 1180, 1182, 1240, 1246, 1249, 1253, 1260, 1299-1326, 1342-1344, 1380, 1385, 1390, 1419-1438, 1527-1539, 1555-1561, 1587, 1642-1647, 1659-1661, 1719-1725, 1786-1788, 1800-1801, 1843, 1845

TOTAL
644
222
66%

Coverage from this branch:
pytest tests/io/complex/sicd_elements/test_sicd_elements_blocks.py --cov=sarpy.io.complex.sicd_elements.blocks --cov-report term-missing

Name
Stmts
Miss
Cover
Missing

sarpy/io/complex/sicd_elements/blocks.py
644
6
99%
1113, 1116, 1118, 1385, 1388, 1390

TOTAL
644
6
99%

performing code review and testing


battery is lasting less than seven days vs. almost a month

Something in the code is significantly lowering battery life on AQ units. Will need to power profile to figure out what is going on. It could be the 5x SCD40 sample time, as an example.

remove power to SCD40 LED, MagTag power/charging LED
do we need?
digitalWrite(SPEAKER_SHUTDOWN, LOW); // off
digitalWrite(NEOPIXEL_POWER, HIGH); // off


support make test on darwin

What this PR does / why we need it:
run make test on darwin os
Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
Fixes #
Checklist:

[ ] Docs included if any changes are user facing

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
13 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.1%) to 33.73%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1/mpi/mpijob_controller.go
4
76.65%

pkg/controller.v1/pytorch/pytorchjob_controller.go
9
58.19%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
3318

Relevant Lines:
9837

💛  - Coveralls

/approve


SBE/BDD Testing

I'm submitting a ...
[x] feature request

Current behavior
Project only has unit testing.
Expected behavior
Would like to see cucumber based SBE testing using feature files, etc.
What is the motivation / use case for changing the behavior?
Would like to use this seed in a calculation heavy project which will require SBE type testing
Please tell us about your environment:
Windows, VisualStudio 2015

Angular Seed Version: 2.0.X
dcedc18bbccaf73266deaba080956ef111e9f158

Node:
node --version = 7.0.0

Hey @pete2014, thanks for giving the seed a try! BDD is already possible with jasmine. SBE is another great feature that has plenty of use cases in development. Although it's a nice feature, I'd prefer to keep it out of the seed for now. We want to satisfy the requirements of most developers and in the same time keep the seed as minimalistic as possible.
As part of your tools/tasks/project directory you can introduce another task which invokes cucumber and implements your SBE features. This way you'll be able to easier update your seed by using git pull upstream master without introducing merge conflicts, and we will be able to keep the seed as minimalistic as possible.

@pete2014 - Were you able to integrate cucumber into the seed?  I was wondering if there is an example somwehere on github that uses it with this seed.

@pete2014 and @mgechev - After spending some more time on this it looks like for some reason the app doesn't start up when using cucumber but it does when using it with jasmine/protractor as is.   The only way I could get it to work is to run serve.e2e before I execute the tests like it says in the instructions.  However this will not allow the project to be tested with continous integration.  What am I missing here?


feat(serviceaccount, pod): set automountServiceAccountToken to false (#1146)

Backport
This will backport the following commits from k8s-24/main to k8s-23/main:

feat(serviceaccount, pod): set automountServiceAccountToken to false (#1146)

Questions ?
Please refer to the Backport tool documentation

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1167

Questions ?
Please refer to the Backport tool documentation


Implement an alerting system for data-catalogue

Problem
We are setting up alerts for service disruption for DataHub and Find-MoJ-Data, but these need somewhere to go.
Questions:

Should these all be fed into the same channels or service-specific channels?
How do we try to minimise 'noise' from these channels

Requirements

[ ] Create relevant alerts Slack / Teams channel(s) for service-relevant alerts
[ ] [OPTIONAL] Create user-facing Slack / Teams channel(s) (TBD) for user-relevant alerts (e.g. changes to domains) or updates to the find-moj-data service

#data-catalogue-alerts set up as part of setting up sentry for find moj data


How to use the past, future and self targets for text generation?

What is your question?
I noticed that new FairSeq models support past, future and self targets for text generation tasks. However, I have been trying to figure out a way of implementing a generator that would allow me to do it, but it seems that it is really hard to get that to work. The issue is mostly in the fact that it is not entirely clear, which models actually support it. The default model handler sets model.supported_targets as ['future'], which mean we only have access to the old default mode, but also many models do not seem to support the feature (I have spent few days now trying to discover right combination of things to do in order to enable this).
The reason I am enthusiastic about this feature is that I have developed a writing theory based prompting system for AI generated fiction writing, where I am able to generate past-(target)-theme, future-(target)-themes for scenes in a story and character-action prompts that I could use with self-target. I would love to build a model based on this as my entry for the NaNoGenMo AI writing competition by November of this year; so I would be willing to do some contributions if I get some guidance.
I have studied this problem (of dramatic arc generation with AI) since 2016 and I strongly believe that this kind of semi-guided method where author / automation (based on theoretical framework used by real authors of fiction) provides dramatic structure and machine just bridges the gap, would be most interesting as it might actually work. Unfortunately traditional language models have lacked bidirectional causality and self-reflection due to unidirectional prompting, while this method would depend on exactly those features. I have already built an early prototype for the prompt generator.
So my questions would be:

Which pretrained models support past, future and self targets for language-modeling tasks?
Would it be sufficient if I just change the default handlers (of supported models) so that their model.supported_targets would be ['past', 'self', 'future']? If not, where could I get proper guidance for doing rest of the coding (I am professional data engineer / scientist with lot of experience on NLP; I would not need that much help)?
If I would like to contribute a generator pipeline for this "more causal" generation task, how would we conduct such work?

Regarding the pretrained models, I would prefer some simple smallish thingie that I can run with single Quadro T1000 (4GB), though I do have occasional free access to bigger machines too.

Sorry I have no knowledge in this field.
All I find out is
In short:
using any lm model, change its supported_target method(i.e.) to return {"future", "past", "self"}, a LanguageModelingTask, add --past-target --future-target --self-target to command line may do your job.
More specifically:

models: FairseqLanguageModel, BARTModel, RobertaModel have the supported_targets. You can add "past", "self" and "future" as you wished.
tasks: LanguageModelingTask , MultilingualLanguageModelingTask utilize those.

if you search targets in these two .py, you will know self.targets are determined by --past-target, --self-target, --future-target. See setup_task
also, you will find dataset is built with self.targets

dataset: MonolingualDataset's _getitem_,_make_source_target has a comment talking about future,self,past targets. Check it out.

Those are all I can find now.
So I do not know about how past-(target)-theme or futrue-(target)-theme should be handled. For MonolingualDataset's comment do you find it makes any sense? If it does, then everything should be ready to go.
fairseq-generate does task.load_dataset. However, fairseq-interactive uses task.build_dataset_for_inference, which does not envoke MonolingualDataset so interactive may not work.
Hope your succeess.
--
For contributing, I guess you have to @ somebody?

Cool, thanks for the swift reply!
I will give it a try and see what comes out of it. I think I would also need to make some modifications to the beam decoder and make it bi-directional. I think this paper has the same idea: https://arxiv.org/pdf/1906.09601.pdf
Do you know if there is some existing decoder that already delivers the same idea (but instead for translation does that for language modeling task)?

Here to share some first impressions.
I decided to try just remove the check that throws the "Unsupported language modeling target" exception, mostly because models do not have setattr implemented and thus supported_targets is read-only. As a model I used the Fariseq Pre-trained  Adaptive LM Wiki 103 v2 model (found it from the documentation, from the pre-trained models part); this model only had future target by default.
With this setup setting the past, self or future targets had not impact to the end result, it was all deterministic.
How could I check if there exists any models, which have more than one target? Somewhere it said that all bidirectional models ought to have both and self targets. By default causal LM's are left-to-right future target models and typically bidirectional models are not used with prompting, since their prompting capabilities was just discovered in 2021. I believe those white papers have not lead to any practical implementations in the frameworks we use these days?
I might try if BART and RoBerta are different than the fairseq models, but I might just give up if those are dead ends and instead try to solve my problem through some other route.
Oh wait, seems like the bidirectional prompting paper is from April 2022: https://openreview.net/forum?id=oH-ePEJ57Nz
Maybe I need to wait one more year :)


Fix COLLATE column_constraint

Was getting this error for migration files contains COLLATE
java.lang.AssertionError: Test failed because the compile output unexpectedly has the errors <[
    1.s line 3:19 - ')', ',', <column constraint real> or '[]' expected, got 'COLLATE'
]>.

Fix is to just import COLLATE.

Going to cut a patch release for this


added ellipsis to table header if needed

Coverage increased (+0.04%) to 76.148% when pulling fa01eb6722a4c4ac45b152be52d1d58829b837e5 on ellipsis_table_header into 6fe102aaee1987d861352a313bfb9d9017fc897a on master.


Support pre-trained word vector for classifier

Implement -pretrainedVectors params

hi I am willing to help this but I am not familiar with cython, any pointer to which part of code should I read first?

Hi @catethos,
You can start from https://github.com/salestock/fastText.py/blob/master/fasttext/fasttext.pyx#L238 to get general idea of
fasttext.skipgram(...)

how we use cython to pass and receive data from python to c++.
I recommend to read this docs first http://cython.readthedocs.io/en/latest/src/tutorial/cython_tutorial.html

Hi @pyk, @catethos,
I sent a PR enabling pretrainedVectors support.
I have compared classifier performance with/without it. It makes a notable difference - especially when there is few training epochs - so I guess it is taking the pretained word vectors into account.

Thanks @gggdomi! Fixed by #93


Not downloading all pics?

What steps will reproduce the problem?

start grabber
set the sources to gelbooru
search for "lolicon -furry -futanari"
click "get all"

What is the Problem?
It doesnt download all 109000+ pictures but only the first 20034 pics (at least it always does for me)
It counts the pages and the pictures correctly but downloads only the first 477 pages (and yes 20034 / 42 [pics per page] is exactly 477)
Idk if thats how its supposed to be but i wanted to load all 109 thousand pictures not only the first 1/5 of it.

Indeed, it seems that Gelbooru does not allow browsing more than 20,000 images.
See http://gelbooru.com/index.php?page=forum&s=view&id=1549 for more info
I'm looking if I can include a fix in the next version.
In the meantime, you can use the "solution" described in the thread above, even if quite tedious. Or refine your search more.

It should be fixed if you replace your Gelbooru model.xml file (it's located in "sites/Gelbooru (2.0)" in your settings folder) by this one: model.xml.
The fix will also be included in next version (the model file will be updated when installing the update).

I replaced the model.xml but uh now it shows the amount of pics (around 110 thousand) as the page amound.
http://puu.sh/s772j/17bbe0272a.png


Add APIM Analytics dashboard widgets

Purpose

From APIM 3.0.0, the users have to access the stream processor dashboard profile to view their corresponding stats. Therefore, to create publisher and store dashboards in the stream processor, the necessary widgets have to be implemented first.

Goals

Implement each dashboard widget and pack them with the default APIM Analytics pack.

Approach

Added the four dashboard widgets

APIMApiCreated
APIMAppCreated
APIMSubscriptions
APIMDeveloperSignups

UI of the added widgets

User stories

These widgets mainly target API publishers. They are able to view the following stats.

Total API created count + Last week's API created count
Total applications created count + Last week's applications created count
Total subscriptions count + Last week's subscriptions count
Total developer signup count + Last week's developer signup count

@Niveathika92 we are planning to make use of this with the next 2.x release. Therefore I think the master branch has to have this change. Can you check and merge, please.

@fazlan-nazeem Ack.
SajithAR(@this) Could you please review and merge.

@sandalu95 Please verify the Node version & the NPM version that you are using in your local machine. FYI, we should use Node 8.8.1v & NPM 5.4.2v.

@sandalu95 When importing lodash, be sure to import only the functions you need.e.g.
import _cloneDeep from 'lodash/cloneDeep';

const dataProviderConfigs = _cloneDeep(providerConfig);


get allways fresh device type, add it also for app resource

At moment when we initialize DeviceDetection userAgent is not populated yet. With this change we will have allwys correct current_device value.

it fix #103

hhvm fails on tests with No code coverage driver available error message.

can you also have a look if this relates to what we did in https://github.com/liip/LiipThemeBundle/pull/113 ?

even calling setCurrentTheme in contructor don't fix that. Looks like somehow setUserAgent is called many times without user agent and we can't use it in FileLocator constructor. This PR fixes it but for now, i will try to check where is real big but it can take time. Merging is up to You. In our project we can use fork.

can you rebase to get the HHVM issue fixed

aside from this it would be good if you could add a test case

i will do it

@lsmith77 if tests are ok i will rebase it. Let me know.

i am still a bit nervous if we are not going to break something again .. but in the previous changes I didn't insist on a test .. so hopefully if we do break something again, then we have a tewst case to prevent another round of regressions

Like I said - we will look for real issue soon. Expect PR.


[Feature] Sample with messaging extension and OAuthPrompt

I have a messaging extension (composeExtension/query) that requires authentication (it searches a 3rd party API). If the user attempts to search but is not logged in, I want to prompt the user to sign in, and once they have successfully signed in, run the search.
I am not sure how to do this, and I think a sample would be good to have since I think this is a common use case.

In case if you don't have access token (or login info), you can return next response:
response = new MessagingExtensionResponse
{
ComposeExtension = new MessagingExtensionResult
{
Type = "auth",
SuggestedActions = new MessagingExtensionSuggestedAction
{
Actions = new List
{
new CardAction
{
Type = ActionTypes.OpenUrl,
Title = "Sign in",
Value = link
}
}
}
}
};

Thanks! How do you determine if you have the access token? In dialog, this is done by just sending an OAuthPrompt which passes a step context of TokenResponse to the next step if the user is already logged in, or if they aren't, prompts them and then passes it on a successful login. I don't understand how I could use a similar workflow in a messaging extension because there wouldn't be any "next step".

Also the example you gave has a direct link to the OAuth flow, but what I'm talking about is using the ConnectionName from app settings like what the OAuthPrompt uses.

In case if you use OAuth Connection setting, you can try something like that:
first check token, then generate link.

Unfortunately the token is always null when I have previously logged in. The example you're giving with the link does not use the oauth connection that OAuthPrompt provides, so authenticating in this way would not save the token so that it can be used elsewhere.

ITeamsContext is always null when running in Teams without using a magic code. When I run in the bot emulator using a magic code, it's not null. I can't test messaging extensions in the bot emulator, though.

Alright, I've got it narrowed down a little. I must be missing something in my Startup because ITeamsContext is always null, but everything in it is just a helper function anyway so I just copied out the pieces I need and got it partially working. If the user is already logged in due to a dialog conversation, the token is available within the composeExtension handler like the example you gave:
            var adapter = (IUserTokenProvider)turnContext.Adapter;
            var token = await adapter?.GetUserTokenAsync(turnContext, "MyConnectionName", null, cancellationToken);

However, if the user is not logged in when they trigger the composeExtension, the token is null in that code. I tried returning an auth type response and that did not work.
                var link = await adapter?.GetOauthSignInLinkAsync(turnContext, "MyConnectionName", cancellationToken);
                return new MessagingExtensionResponse
                {
                    ComposeExtension = new MessagingExtensionResult
                    {
                        Type = "auth",
                        SuggestedActions = new MessagingExtensionSuggestedAction
                        {
                            Actions = new List<CardAction>
                            {
                                new CardAction
                                {
                                    Title = "You are not authorized. Please log in.",
                                    Value = link,
                                    Type = ActionTypes.OpenUrl
                                }
                            }
                        }
                    }
                };

That code almost works. It displays "You are not authorized. Please log in.
You'll need to sign in to use this app." in my message extension window where sign in is a link that opens the OAuth popup. I am able to sign in to the popup but signing in does not post a message to my endpoint; I would expect signin/verifyState here like I get when logging in via the dialog OAuthPrompt. Since the result of the oauth popup doesn't go anywhere, when the messaging extension is automatically retried, there is still no token.
I also tried the same code but with Type = ActionTypes.Signin and that doesn't work at all. It displays "Something went wrong. Please try again."

Hi @Blackbaud-ChristiSchneider,
Did you use https://docs.microsoft.com/en-us/azure/bot-service/bot-builder-authentication?view=azure-bot-service-4.0&tabs=csharp%2Cbot-oauth#use-an-oauth-prompt-to-sign-the-user-in-and-get-a-token ? What provider do you use (facebook, Google, generic etc)?
ITeamsContext can be empty in some cases. Did you try this code (with TeamsMiddleware middleware) in Teams ?

Yes I used that page to create my app. However, I don't see how you would start a dialog from a messaging extension.
We have an in-house OAuth provider, so I registered it in Azure as "Generic Oauth 2".
I tried the middleware as shown in the README for this repo but ITeamsContext was always null when running the app inside of Teams, and was always not null when running in the Bot Framework Emulator. However, I have a workaround for that (copying out the relevant code) and this repository is going to be replaced so I won't put too much effort into diagnosing that.

Okay I figured out how to do this and will post a sample when I clean it up a little. I'm not sure why this works this way (I think this may be a miss somewhere) but signing in from the messaging extension does not trigger signin/verifystate. Instead, it includes the 6 digit magic code as the state property of the composeExtension/query. You can use this code to get a token.
var magicCodeObject = turnContext.Activity.Value as JObject;
var magicCode = magicCodeObject.GetValue("state", StringComparison.Ordinal)?.ToString();
var token = await adapter.GetUserTokenAsync(turnContext, _appSettings.ConnectionName, magicCode, cancellationToken).ConfigureAwait(false);

This also caches the token so that the following code returns the token in the future:
var adapter = (IUserTokenProvider)turnContext.Adapter;
var token = await adapter?.GetUserTokenAsync(turnContext, _appSettings.ConnectionName, null, cancellationToken);

Hi - we've got a PR with an example of this using the vNext of the Bot Framework SDK. You can check it out here: https://github.com/microsoft/botbuilder-dotnet/pull/2646


What about the Batch account does that enables move?

Does Batch Account enables move??

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

ID: 76c1c185-685f-27e0-e634-844b510b1834
Version Independent ID: 09375778-5354-ab44-c5c6-94c2aebe34bc
Content: Move Azure resources to new subscription or resource group
Content Source: articles/azure-resource-manager/resource-group-move-resources.md
Service: azure-resource-manager
GitHub Login: @tfitzmac
Microsoft Alias: tomfitz

@Anmolgan81 - yes, Batch Accounts can be moved. They are part of the Batch service.

#please-close


Fix some issues related to sheet name

Throw exception with invalid sheetname during designtime
Schema should be always useful for any existed sheet specified during runtime (invalid type data would cause exception)

VS buildable but not FAKE. Let me close it first.


"dl_main: Assertion 'main_map != NULL' failed!" when executing mipsel binary

Hi, I encountered some difficulties recently. I sincerely ask for a help.
These days, I am trying to execute a binary compiled for mips, so I write a quite simple program below:
int main(){
	int a;
	a=32;
}

and then compile it by command:mipsel-linux-gnu-gcc ./tests/hello.c -o ./tests/hello-mipsel.
After that, I run the binary through ./usercorn run  ./tests/hello_mipsel
But it doesn't work and throw an assertion error.:
Inconsistency detected by ld.so: rtld.c: 983: dl_main: Assertion 'main_map != NULL' failed!
Details for trace:
0xc23c80: lb $v0, ($s6)                                      |                 | R c338a4
0xc23c84: bnez $v0, 0xc23bcc                                 |
0xc23c88: move $at, $at                                      |
0xc23c8c: lw $a0, 0x270($fp)                                 | a0 = 0x00000002 | R bfffe980
R 0x00c338a4: 00                                             [.                   ] R
R 0xbfffe980: 02000000                                       [....                ] R
0xc23c90: addiu $a1, $fp, 0x20                               | a1 = 0xbfffe730
0xc23c94: move $a2, $s5                                      | a2 = 0x0000000a
0xc23c98: addiu $v0, $zero, 0x1032                           | v0 = 0x00001032
Inconsistency detected by ld.so: rtld.c: 983: dl_main: Assertion `main_map != NULL' failed!
[note : Actually you can see a fault here!!!!]
0xc23c9c: syscall                                            | v0 = 0x0000005c
writev(2, 0xbfffe730, 0xa) = 0x5c
0xc23ca0: move $sp, $fp                                      | sp = 0xbfffe710
0xc23ca4: lw $ra, 0x26c($sp)                                 | ra = 0x00c241ec | R bfffe97c
0xc23ca8: lw $fp, 0x268($sp)                                 | s8 = 0xbfffe9d8 | R bfffe978
0xc23cac: lw $s7, 0x264($sp)                                 | s7 = 0x00c31000 | R bfffe974
0xc23cb0: lw $s6, 0x260($sp)                                 | s6 = 0x00c44ef0 | R bfffe970
0xc23cb4: lw $s5, 0x25c($sp)                                 | s5 = 0x00400034 | R bfffe96c
0xc23cb8: lw $s4, 0x258($sp)                                 | s4 = 0x00c452c8 | R bfffe968
0xc23cbc: lw $s3, 0x254($sp)                                 | s3 = 0x00c2b810 | R bfffe964
0xc23cc0: lw $s2, 0x250($sp)                                 | s2 = 0x00c2ea30 | R bfffe960
0xc23cc4: lw $s1, 0x24c($sp)                                 | s1 = 0x00000000 | R bfffe95c
0xc23cc8: lw $s0, 0x248($sp)                                 |                 | R bfffe958
0xc23ccc: jr $ra                                             |
0xc23cd0: addiu $sp, $sp, 0x270                              | sp = 0xbfffe980
0xc241ec: lw $ra, 0x24($sp)                                  | ra = 0x00c2bdfc | R bfffe9a4
R 0xbfffe958: 00000000 00000000 30eac200 10b8c200 c852c400   [........0........R..] R
   0xbfffe96c: 34004000 f04ec400 0010c300 d8e9ffbf ec41c200<EMAIL_ADDRESS>0xc241f0: jr $ra                                             |
0xc241f4: addiu $sp, $sp, 0x28                               | sp = 0xbfffe9a8
0xc2bdfc: lw $gp, 0x20($sp)                                  |                 | R bfffe9c8
R 0xbfffe9a4: fcbdc200                                       [....                ] R
0xc2be00: lw $t9, -0x7f8c($gp)                               | t9 = 0x00c2e0a0 | R c45074
0xc2be04: bal 0xc2e0a0                                       | ra = 0x00c2be0c
0xc2be08: addiu $a0, $zero, 0x7f                             | a0 = 0x0000007f
0xc2e0a0: lui $gp, 2                                         | gp = 0x00020000
R 0xbfffe9c8: 00d0c400                                       [....                ] R
R 0x00c45074: a0e0c200                                       [....                ] R
0xc2e0a4: addiu $gp, $gp, -0x10a0                            | gp = 0x0001ef60
0xc2e0a8: addu $gp, $gp, $t9                                 | gp = 0x00c4d000
0xc2e0ac: lw $a2, -0x7ea8($gp)                               | a2 = 0x00c45bd8 | R c45158
0xc2e0b0: move $a1, $a0                                      | a1 = 0x0000007f
0xc2e0b4: move $a0, $a1                                      |
0xc2e0b8: addiu $v0, $zero, 0x1096                           | v0 = 0x00001096
exit_group(127)
0xc2e0bc: syscall                                            | v0 = 0x00000000
R 0x00c45158: d85bc400                                       [.[..                ] R

Later, I search the source code of glibc/elf/rtld.c and glibc/elf/dl-object.c
//from rtld.c
	main_map = _dl_new_object ((char *) "", "", lt_executable, NULL,
                                 __RTLD_OPENEXEC, LM_ID_BASE);
    assert (main_map != NULL);

//from dl-object.c
  new = (struct link_map *) calloc (sizeof (*new) + audit_space
                                    + sizeof (struct link_map *)
                                    + sizeof (*newname) + libname_len, 1);
  if (new == NULL)
    return NULL;

Function calloc may return a NULL point. Unfortunately, I can't figure out why this happens. Is this error relevant to the usercorn emulation of 32-bit MIPS?
Besides, I also try to use qemu-mipsel to run the hello_mipsel and it can work successfully. But there is something wrong when using usercorn to execute this binary.
I am a newbie at this and therefore I need your help.
Any help or remark (or question) would be appreciated.
Thanks.
Details for the binary:
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x4005a0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          6660 (bytes into file)
  Flags:                             0x10001007, noreorder, pic, cpic, o32, mips2
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         11
  Size of section headers:           40 (bytes)
  Number of section headers:         33
  Section header string table index: 30

Can you build the failing binary statically and upload it so I can run it?

Thanks for your prompt reply!
And I upload source code, static-binary and dynamic-binary with ld.so and libc.so.
binary_for_mipsel.zip
Obviously I can't run the static binary, but the error is different with dynamic one.
Some instructions of static binary may trigger unmapped memory write
$ ./usercorn run ./tests/hello_mipsel_static
invalid write: @0xffff9010, 0x4 = 0x3
----------------------------------------
Error: Invalid memory write (UC_ERR_WRITE_UNMAPPED)

In addition, I provide other information for you.
Trace for static binary:
getenv+0x168
0x40ac74: beqz $v0, 0x40ad14                                 |
R 0xbfffed28: 78914800 78914800 04000000 28000000 00000000   [x.H.x.H.....(.......] R
   0xbfffed3c: 00004a00 202c4a00                              [..J. ,J.            ]
0x40ac78: lw $gp, 0x18($fp)                                  |                 | R bfffed60

__libc_message+0x6c
0x40ad14: lui $a0, 0x47                                      | a0 = 0x00470000
R 0xbfffed60: 40904a00<EMAIL_ADDRESS>               ] R
0x40ad18: addiu $a1, $zero, 0x882                            | a1 = 0x00000882
0x40ad1c: addiu $a0, $a0, 0x62a8                             | a0 = 0x004762a8
0x40ad20: addiu $v0, $zero, 0xfa5                            | v0 = 0x00000fa5
0x40ad24: syscall                                            | v0 = 0x00000003 | R 4762a8
open("/dev/tty", 2178, 0x4762a8) = 0x3

__libc_message+0x118
0x40ad28: beqz $a3, 0x40ae64                                 |
R 0x004762a8: 2f646576 2f747479 00000000                     [/dev/tty....        ] R
0x40ad2c: move $s7, $v0                                      | s7 = 0x00000003

__libc_message+0x120
0x40ad30: lw $v0, -0x7654($gp)                               | v0 = 0xffff9010 | R 4a19ec
R 0x004a19ec: 00000000                                       [....                ] R
0x40ad34: rdhwr $v1, $29                                     | v1 = 0x00000000
0x40ad38: addu $v0, $v0, $v1                                 |
0x40ad3c: b 0x40ac88                                         |
invalid write: @0xffff9010, 0x4 = 0x3
Invalid memory write (UC_ERR_WRITE_UNMAPPED)
[pc]
0x40ad40: sw $s7, ($v0)
0x40ad44: lb $v1, 1($v0)
0x40ad48: bne $v1, $s2, 0x40acb4
0x40ad4c: move $at, $at
0x40ad50: bne $s4, $s0, 0x40acd4
0x40ad54: move $at, $at
0x40ad58: lb $v1, 1($s1)
0x40ad5c: bne $v1, $s2, 0x40acd4
0x40ad60: lw $t9, -0x7fc0($gp)
0x40ad64: lw $v0, 0x20($fp)
0x40ad68: addiu $s1, $s1, 2
0x40ad6c: addiu $s6, $s3, 1
0x40ad70: addiu $v1, $v0, 4
0x40ad74: lw $a1, ($v0)
0x40ad78: sw $v1, 0x20($fp)
0x40ad7c: move $a0, $a1
[memory map]
  0x400000-0x48e000 r-x [exe] ./tests/hello_mipsel_static
  0x49d000-0x4a3000 rw- [exe] ./tests/hello_mipsel_static(0x8d000)
  0x4a3000-0x4a4000 rw- [brk]
  0xbf800000-0xc0000000 rwx [stack]
[registers]
s0: 0x489178
s3: 0x28
s5: 0x4a0000
s7: 0x3
a1: 0x882
at: 0xfffffff8
a3: 0x80808080
s6: 0x4a2c20
s4: 0x0
t0: 0xfefefeff
t8: 0x10
sp: 0xbfffed48
gp: 0x4a9040
t3: 0x4a0ee4
t5: 0x1
t2: 0x0
s2: 0x4
t7: 0x4a1aa4
t6: 0x4a0000
s8: 0xbfffed48
ra: 0x40ac74
a0: 0x4762a8
t9: 0x4192a0
s1: 0x489178
a2: 0x4762a8
v1: 0x0
v0: 0xffff9010
t1: 0x2e
t4: 0x49f6b8
[callstack]
  0x0
  0x400640
  0x400888 __libc_start_main+0x8
  0x400ce8 __libc_setup_tls+0x8
  0x40af60 __libc_fatal+0x4
  0x40ac18 __libc_message+0x8
  0x40ad40 __libc_message+0x130
0x40ad40: sw $s7, ($v0)                                      |                 | W ffff9010
W 0xffff9010: 03000000                                       [....                ] W
----------------------------------------
Error: Invalid memory write (UC_ERR_WRITE_UNMAPPED)

version of mipsel-linux-gnu-gcc:
$ mipsel-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=mipsel-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/mipsel-linux-gnu/5/lto-wrapper
Target: mipsel-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-mipsel-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-mipsel-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-mipsel-cross --with-arch-directory=mips --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-multiarch --disable-werror --enable-multilib --with-arch-32=mips2 --with-tune-32=mips32r2 --with-fp-32=xx --enable-targets=all --with-arch-64=mips3 --with-tune-64=mips64r2 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=mipsel-linux-gnu --program-prefix=mipsel-linux-gnu- --includedir=/usr/mipsel-linux-gnu/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)

Sorry I'm coming back to this so late.
The static binary is failing in __libc_setup_tls
Here we can see when it calls rdhwr to read the thread-local storage register, it returns 0:
0x40ad34: rdhwr $v1, $29                                     | v1 = 0x00000000
There's probably an instruction or Linux syscall for MIPS to set the TLS register, maybe it's not implemented in usercorn or not working.
The dynamic binary returning 0 from calloc - can you find the call to calloc in the trace, see which syscalls it makes? Look for a brk or mmap.

;; The TLS base pointer is accessed via "rdhwr $3, $29".  No current
;; MIPS architecture defines this register, and no current
;; implementation provides it; instead, any OS which supports TLS is
;; expected to trap and emulate this instruction.  rdhwr is part of the
;; MIPS 32r2 specification, but we use it on any architecture because
;; we expect it to be emulated.  Use .set to force the assembler to
;; accept it.

Thanks for coming back and answering my questions.
It's been a while, so I rerun the dynamic binary with -strace.
mipsel_test_binary.zip
Details for strace:
spiderman@spiderman-virtual-machine:~/usercorn$ ./usercorn run -strace ./tests/test_mipsel
brk(0x0) = 0x412000
mmap2(0x0, 0x1000, 3, 2050, 0, 0x0) = 0xc34000
Inconsistency detected by ld.so: rtld.c: 983: dl_main: Assertion `main_map != NULL' failed!
writev(2, 0xbfffe610, 0xa) = 0x5c
exit_group(127)

Therefore, mmap makes calloc returning 0.
Strangely, mmap2(0x0, 0x1000, 3, 2050, 0, 0x0) seems work well with the return value of 0xc34000.
I am sorry then, I didn't quite understand why the call to calloc matters?
Additionally, I contrast static-binary compiled by mipsel-linux-gnu-gcc in my machine
with usercorn/bins/mipsel.linux.elf.
Perhaps one difference is the version of ISA.
 spiderman@spiderman-virtual-machine:~/usercorn$ file ./bins/mipsel.linux.elf
./bins/mipsel.linux.elf: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, not stripped
spiderman@spiderman-virtual-machine:~/usercorn$ file ./tests/test_mipsel_static
./tests/test_mipsel_static: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=0ba8f4b831b8bd28b11f6e69a1f85f247e5eda80, not stripped

I wonder if the limitation you mentioned can be interpreted in a way that only binary of MIPS 32r2 version can work well in usercorn.

Can you run with -v so we can see the memory map layout on crash?

The memory map specifically as follows:
spiderman@spiderman-virtual-machine:~/usercorn$ file ./tests/test_mipsel
./tests/test_mipsel: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked, interpreter /lib/ld., for GNU/Linux 3.2.0, BuildID[sha1]=916234c4dc29ecdb318f5e33d2c3726cc323dedc, not stripped

spiderman@spiderman-virtual-machine:~/usercorn$ ./usercorn run -v -strace ./tests/test_mipsel
[entry @ 0xc11d00]
0xc11d00: move $t9, $ra
0xc11d04: bal 0xc11d0c
0xc11d08: move $at, $at
0xc11d0c: lui $gp, 4
0xc11d10: addiu $gp, $gp, -0x4d0c
0xc11d14: addu $gp, $gp, $ra
0xc11d18: move $ra, $t9
0xc11d1c: lw $a0, -0x7fe8($gp)
0xc11d20: sw $a0, -0x7ff0($gp)
0xc11d24: move $a0, $sp
0xc11d28: addiu $sp, $sp, -0x10
0xc11d2c: lw $t0, -0x7fe4($gp)
0xc11d30: addiu $t0, $t0, 0xd3c
0xc11d34: bltzal $t0, 0xc11d3c
0xc11d38: move $at, $at
0xc11d3c: subu $t0, $ra, $t0
[stack]
0xbfffed90: 00000000 00000000 00000000 00000000 00000000   [....................]
0xbfffeda4: 00000000 00000000 00000000                     [............        ]
[stack pointer]
0xbfffedb0: [skipped 0x64 null bytes]
[memory map]
  0x400000-0x401000 r-x [exe] ./tests/test_mipsel
  0x410000-0x412000 rw- [exe] ./tests/test_mipsel
  0xc11000-0xc34000 r-x [interp] /lib/ld.so.1
  0xc44000-0xc46000 rw- [interp] /lib/ld.so.1(0x23000)
  0xbf800000-0xc0000000 rwx [stack]
=====================================
==== Program output begins here. ====
=====================================
brk(0x0) = 0x412000
mmap2(0x0, 0x1000, 3, 2050, 0, 0x0) = 0xc34000
Inconsistency detected by ld.so: rtld.c: 983: dl_main: Assertion `main_map != NULL' failed!
writev(2, 0xbfffe610, 0xa) = 0x5c
exit_group(127)
[memory map]
  0x400000-0x401000 r-x [exe] ./tests/test_mipsel
  0x410000-0x412000 rw- [exe] ./tests/test_mipsel
  0xc11000-0xc34000 r-x [interp] /lib/ld.so.1
  0xc44000-0xc46000 rw- [interp] /lib/ld.so.1(0x23000)
  0xbf800000-0xc0000000 rwx [stack]
[registers]
ra: 0xc23e1c
a2: 0xa
s4: 0xbfffe81a
t0: 0xfefefeff
t1: 0x0
a0: 0x2
t3: 0xffffffff
t4: 0x20
a1: 0xbfffe610
s0: 0x0
s2: 0x0
s7: 0xbfffe810
t2: 0xa0000000
t5: 0xbfffe898
s1: 0xbfffe8a4
s6: 0xc338a4
s8: 0xbfffe5f0
v0: 0x1032
v1: 0xc338a4
sp: 0xbfffe5d8
a3: 0x80808080
s3: 0xbfffe610
s5: 0xa
t9: 0xc2e720
[callstack]
  0x0
  0x0
  0x0
  0x0

That mmap seems bad, like it was mapped into the middle of ld.so!
mmap2(0x0, 0x1000, 3, 2050, 0, 0x0) = 0xc34000

  0xc11000-0xc34000 r-x [interp] /lib/ld.so.1
  0xc44000-0xc46000 rw- [interp] /lib/ld.so.1(0x23000)

I have noticed that now!
Does usercorn lead to that ill-mmap? Would you fix it?
Or Could you offer a solution?

I noticed that now!
Does usercorn lead to that ill-mmap? Would you fix it?
Or Could you offer a solution?

Can you run with the repl, e.g. ./usercorn run -repl and run the maps command to see what the mappings are before the target runs?

spiderman@spiderman-virtual-machine:~/usercorn$ ./usercorn run -repl ./tests/test_mipsel
0xc11d00> maps
Memory map:
0x400000-0x401000 r-x [exe] ./tests/test_mipsel
0x410000-0x412000 rw- [exe] ./tests/test_mipsel
0xc11000-0xc34000 r-x [interp] /lib/ld.so.1
0xc44000-0xc46000 rw- [interp] /lib/ld.so.1(0x23000)
0xbf800000-0xc0000000 rwx [stack]
0xc11d00>

Oh, I bet this is related to thread local storage.
0x40ad34: rdhwr $v1, $29 from the static trace reads the TLS register and it comes back as 0
check the other trace for a similar instruction.

See here: https://github.com/unicorn-engine/unicorn/issues/407


[Request] Ragdolls for chams.

I mean, we have ragdolls applied for glow already, why not added to chams too, and I think I see some issue about this and people said added to chams is more complicated and need more than just applied simple code, like glow to chams.
But anyways, I this it's a good thing to added.

exemple.

404 - image not found!

chams are a DrawModelExecute thing because they use materials.
ragdolls don't pass through DME. (we can prove this by hooking it and returning without calling the original, all players will be invisible yet ragdolls still render, even while in motion)
i saw a thread on UC but i don't know if it allows you to modify the material.

404 - image not found!

Updated.

chams are a DrawModelExecute thing because they use materials.
ragdolls don't pass through DME. (we can prove this by hooking it and returning without calling the original, all players will be invisible yet ragdolls still render, even while in motion)
i saw a thread on UC but i don't know if it allows you to modify the material.

There is a fix on UC - https://www.unknowncheats.me/forum/counterstrike-global-offensive/366471-dme-weapon-chams.html


Documentation: Typo in section "this parameters in callbacks"?

In the Handbook for functions http://www.typescriptlang.org/docs/handbook/functions.html, you write to this example
class Handler {
    info: string;
    onClickGood = (e: Event) => { this.info = e.message }
}

This works because arrow functions don’t capture this, so you can always pass them to something that expects this: void.

It's confusing. I think it should be writte as

This works because arrow functions don’t capture this where they are invoked, so you can always pass them to something that expects this: void.

or alternative

This works because arrow functions capture this where they are created, so it is safe to pass them to something that expects this: void.

Handbook has been rewritten


[Installation] installing Google's sparse hashmap without root

Is there an existing issue for this?

[X] I have searched the existing issues

Have you followed all the steps in the FAQ?

[X] I have tried the steps in the FAQ.

Current Behavior
I've installed sparse hashmap in ~/.local/lib following https://github.com/mit-han-lab/torchsparse/issues/15 How do I reference it?
Error Line
No such file or directory #include <sparsehash/internal/sparseconfig.h>
Environment
- GCC:
- NVCC:
- PyTorch:
- PyTorch CUDA:

Full Error Log

Error Log
[PUT YOUR ERROR LOG HERE]

Hi @hdacnw, please refer to this file for the installation of Google Sparse Hash. https://github.com/sparsehash/sparsehash/blob/master/INSTALL

If you want to simply install google-sparsehash to build your Torchsparse in developer mode, you can install sparsehash with conda. Please refer to here.