sources paths are incorrect in declarationMap files (*.d.ts.map) emitted by tsdx

Current Behavior
When using the declarationMap option in tsconfig.json, the sources array in declaration map files does not contain correct relative paths.  Repro steps:

git clone https://github.com/justingrant/ts-declaration-map-repro.git
cd ts-declaration-map-repro
yarn
yarn run with-tsc - this will simply run tsc against this repo.
Open ./dist/index.d.ts.map. It will begin with:
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.tsx"].  Note the correct relative path to index.tsx
yarn run with-tsdx which uses tdsx instead of tsc but uses the same TS config.
Open ./dist/index.d.ts.map again. Here's what you'll see:
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["src/index.tsx"].  Note that the path to index.tsx is incorrectly relative to the project root, not relative to dist.

Expected behavior
Correct relative path to index.tsx (../src/index.tsx) in the map file's sources array.
Suggested solution(s)
I'm assuming that there's a way to configure rollup-plugin-typescript2 so that declaration maps are emitted with the correct paths.
Additional context
Note that only declaration map files are affected. Relative paths in regular sourcemap files works fine.
I'm not sure if this is a problem with tsdx or rollup-plugin-typescript2. But I didn't see any mention of this problem in rollup-plugin-typescript2's issue list, so I figured that tsdx may be the culprit because it's the new kid on the block.  I'm assuming (perhaps naively) that if the problem was in rollup-plugin-typescript2 that it would have been reported in its GitHub issues already.
At first I thought that this problem was related to #465, but I think that issue is solely about how to handle the declarationDir config setting which I'm not using at all. Instead, I'm relying on the same outDir folder for both transpiled output and for declaration output.
This issue may be a dupe of #135, but I'm not sure, because #135 has a much more complex config. But the problem does look similar: in both issues the relative path to the source files is missing in declaration maps emitted by tsdx.
BTW, great library! Glad you're building this.
Your environment

Software
Version(s)

TSDX
<EMAIL_ADDRESS>

TypeScript
<EMAIL_ADDRESS>

Browser
n/a (this is a build issue)

npm/Yarn
<EMAIL_ADDRESS>

Node
v12.13.1

Operating System
MacOS Catalina 10.15.2

Since I reviewed #465 / #468, this definitely does seem related to them, as well as #135 . Based on the comments in #135, it sounds like adding declarationDir might work as a workaround for this once #468 is merged.
A very relevant note is that there is this function in the codebase moveTypes:
https://github.com/jaredpalmer/tsdx/blob/4f6de1083393057903a1837fb6658f8058ee832f/src/index.ts#L104-L112
Type definitions originally get generated by rpts2 in dist/src/ and are then moved to dist/ by TSDX.
I suspect that if TSDX uses, internally as a default, declarationDir: 'dist/', that might fix the issue, or at least get closer.
As they're generated in dist/src/ instead of the output directory dist/ it might also be a bug in rpts2, not really sure at this time.

Potentially related to https://github.com/ezolenko/rollup-plugin-typescript2/issues/136 , which goes over why rpts2's type definitions output structure mirrors that of your source structure

Looked into it a bit more and there's very little code in rpts2 around .d.ts.map files, they're entirely produced by the TS Language Service. So if anything, the problem is how the input is passed in.
Hard for me to really dig into it any further as that gets into Language Service specifics which I don't know anything about. Can try replicating this with plain rollup and rpts2 and see if it still occurs and then can see if we can get any help from the rpts2 folks.
In your case, you have specified an outDir in tsconfig.json, which tsc can interpret, whereas tsdx does not currently interpret it (there's a number of issues around this), which might be related.

@agilgur5 - To verify your notes above, I hacked useTsconfigDeclarationDir: true in createRollupConfig.js's rpts2 and the declaration map's sources paths are emitted properly.  This is good news, because this issue should be fixed by #468.
That said, setting useTsconfigDeclarationDir: true also works if I don't have a declarationDir setting in my tsconfig.json (tsc handles that case by using outDir for the declaration directory).  Unfortunately, the current code in #468 won't work for that case. Excerpt:
https://github.com/jaredpalmer/tsdx/blob/77bc3036a870de20949a4a81fa7498ac7b04aed1/src/createRollupConfig.ts#L156-L158
If my tsconfig has no declarationDir, then the code above returns false, which is not desired. I'll comment on #468 to continue the conversation over there.
BTW, while stepping through tsdx code to investigate this problem, I discovered two additional problems with tsconfig parsing: #483 (comments and other extended JSON features are not handled the same as tsc does) and #484 (extends in tsconfig files is ignored by tsdx but handled properly by tsc). Both of these have a common root cause: tsdx is parsing tsconfig.json differently than tsc. Luckily TS exposes its tsconfig parser in an API.
I just updated the repro repo for this issue (https://github.com/justingrant/ts-declaration-map-repro) to remove problematic JSON that triggered #483 these issues, to avoid complicating reproes of this issue. I also removed declarationDir from my repo's config to better demonstrate the problem noted above with #468.

@agilgur5 - To verify your notes above, I hacked useTsconfigDeclarationDir: true in createRollupConfig.js's rpts2 and the declaration map's sources paths are emitted properly. This is good news, because this issue should be fixed by #468.

Thanks for checking this! So #468 will create a workaround for this bug. I think we can try adding declarationDir: paths.appDist, to tsconfigDefaults as a full fix for this as I wrote above.

That said, setting useTsconfigDeclarationDir: true also works if I don't have a declarationDir setting in my tsconfig.json (tsc handles that case by using outDir for the declaration directory). Unfortunately, the current code in #468 won't work for that case.
If my tsconfig has no declarationDir, then the code above returns false, which is not desired. I'll comment on #468 to continue the conversation over there.

Per my comments there, let's not mix outDir support with declarationDir support. As I wrote here, outDir is not really supported by TSDX right now, so adding useTsconfigDeclarationDir support for it will still cause other issues.
The above declarationDir: paths.appDist, is probably the optimal fix, and when outDir support is added we'll have to override that.

BTW, while stepping through tsdx code to investigate this problem, I discovered two additional problems with tsconfig parsing: #483 (comments and other extended JSON features are not handled the same as tsc does) and #484 (extends in tsconfig files is ignored by tsdx but handled properly by tsc). Both of these have a common root cause: tsdx is parsing tsconfig.json differently than tsc. Luckily TS exposes its tsconfig parser in an API.

Great finds! Will follow-up in those.

I also removed declarationDir from my repo's config to better demonstrate the problem noted above with #468.

Should probably make this a separate branch as it's a more specific problem.

let's not mix outDir support with declarationDir support

Agreed. My outDir is ./dist. If that's tsdx's default then that explains why I didn't notice any problems with outDir. ;-)

I think we can try adding declarationDir: paths.appDist to tsconfigDefaults as a full fix for this as I wrote above. I'll create a PR for that on top of #468's code.

That sounds like a good solution.

Should probably make this a separate branch as it's a more specific problem.

The current master branch of https://github.com/justingrant/ts-declaration-map-repro has no declarationDir and no trailing commas. The original version had "declarationDir": "./dist" and one trailing comma. My goals when revising the repo were:

remove tsconfig syntax (a trailing comma) that triggered #483, because that would have prevented verifying #468 because tsconfig.json was not parsed successfully.  I didn't think that my repo needed a repro for #483 because that repro was so obvious: just add a trailing comma or a comment to tsconfig.
clarify the case which is not going to be fixed by #468, which is the case when declarationDir is not included in tsconfig. AFAIK, the other case (where declarationDir is present) is already covered by unit tests included with #468.

Given the explanation above, would a new branch still be helpful?  I'm happy to add another branch but I'm not sure what should be in it. Could you clarify what other repro(s) you think would be useful in this repo?

Agreed. My outDir is ./dist. If that's tsdx's default then that explains why I didn't notice any problems with outDir. ;-)

Or rather, not yet you didn't 😅😅😅 See https://github.com/jaredpalmer/tsdx/pull/468#issuecomment-581436403 for some of the other problems around outDir.

remove tsconfig syntax (a trailing comma) that triggered #483, because that would have prevented verifying #468 because tsconfig.json was not parsed successfully.  I didn't think that my repo needed a repro for #483 because that repro was so obvious: just add a trailing comma or a comment to tsconfig.

Yea that change is fine and I agree I don't think it necessarily needs a repro either. Though repros are always helpful so a maintainer doesn't need to like create the code themselves. This case is also a bit unique as it's a silent error, so you'd only notice when things are different from expected.

clarify the case which is not going to be fixed by #468, which is the case when declarationDir is not included in tsconfig. AFAIK, the other case (where declarationDir is present) is already covered by unit tests included with #468.

Ok, gotcha. I think the original case is easier to understand the root cause, but that makes sense.
Well the unit tests don't check that index.d.ts.map is correct (just that it exists), which is the core issue here.

Given the explanation above, would a new branch still be helpful? I'm happy to add another branch but I'm not sure what should be in it. Could you clarify what other repro(s) you think would be useful in this repo?

I think this is fine as at least I've already grasped it and will probably be the one to PR a fix. Thanks for the clarification around the changes!

@agilgur5 - All sounds good. I had one question about your proposed fix: (from your comment in #468)

The proposed fix I reference above would add a default declarationDir, so that would ensure the same code path regardless.

Once that fix is in place, will useTsconfigDeclarationDir always be set to true, instead of the conditional code in #468?  If not, then how would it fix the current issue in the case where tsconfig.json doesn't have a declarationDir?

Once that fix is in place, will useTsconfigDeclarationDir always be set to true, instead of the conditional code in #468?

Yup, it would have to be. I'm actually working on that right now and stuck on some failing tests.
Running into an issue where even with declarationDir set to dist//paths.appDist, typings still get put into dist/src/. The index.d.ts.map file is correct from that directory (../../src/index.ts), but still confused why it's not in dist/.
Weirdly enough, when using declarationDir: 'typings/' as in #468 , index.d.ts.map is in typings/, no added src/ and is also correct (../src/index.ts) 😕

Figured out that the problem was that #468 changed the rootDir to ./src from ./, changing all tests to also use ./src fixes this... but all templates and lots of code out there from the templates have rootDir: './' already set, so requiring rootDir: './src' is actually breaking 😭 😞 😖
Can do some internal deprecation of code to workaround this, but super not ideal 😕

OH. I just noticed your repro also has rootDir: './src' set. When it's ./, we get "sources": ["index.ts"], which would point to the compiled version. That's still not correct, and without moveTypes it'd be in dist/src/ still pointing to index.ts (which is in plain dist), but worth noting.

@jaredpalmer , @agilgur5 , @sw-yx ,
Hi there, I've managed to set this up to work, with a workaround because of the configuration of tsdx for rollup-plugin-typescript2 .
const paths = require('typescript-transform-paths').default
const transformer = (service) => {
  return {
    before: [paths(service.getProgram())],
    after: [paths(service.getProgram())],
    afterDeclarations: [paths(service.getProgram())]
  }
}

module.exports = {
  rollup(config, options) {

    // this is the rollup ts plugin, but I can't add transformers on the tsdx config, so I overwrote it
    config.plugins[5] = tsPlugin({
      verbosity: 3,
      transformers: [transformer],
      exclude: ['./dist'],
    })

    return config
  }
}

It's finally generating the right paths on declaration files, working nice on vscode and monorepos.
So, my question here we'll be: can you add support for transformers for this plugin? I'know it's not a stable api on the plugin( they said it already, this was created before the plugins support on ts), but it seems they're not ready yet to fully support the native behavior. In the meanwhile, this solves the issue, and helps users to add custom plugins to typescript.

@ibraelillo this issue is already tagged as "workaround available" because there is already one available as is written here and in the related issues, it is setting your declarationDir to dist. Which is quite a bit simpler than yours.
I also already added a PR to do that by default in #488 that is linked above but have not merged it because it is actually an upstream issue and the change is a bit breaking if anyone is using a Rollup plugin that operates on declarations with TSDX (c.f. #80 ), but otherwise safe to use as a workaround.
And I had already filed the upstream issue https://github.com/ezolenko/rollup-plugin-typescript2/issues/204 linked above and then made an upstream PR myself linked above https://github.com/ezolenko/rollup-plugin-typescript2/pull/221 . I've been quite busy at work so unfortunately I haven't been able to put in much OSS time, but that was actually my top priority to get into for v0.13.x (now I've waited too long to release v0.14 as a result). The maintainer did not provide much support there either so some bugs have caused it to stall.

So, my question here we'll be: can you add support for transformers for this plugin? I'know it's not a stable api on the plugin( they said it already, this was created before the plugins support on ts), but it seems they're not ready yet to fully support the native behavior. In the meanwhile, this solves the issue, and helps users to add custom plugins to typescript.

I have not confirmed the fix myself, but as I wrote above, there's a much much simpler way to solve the issue and I'm focused on the root cause as opposed to adding increasingly messier and more brittle workarounds that will cause added headaches to support.
I don't think we want to support TS transformers at this time, as not only are they an unstable API that isn't really supported, they are also not very compatible -- you'd need to add support in tsdx test and tsdx lint, tsc --noEmit, VSCode plugins, etc, etc, etc. Compatibility issues are some of the most popular TSDX issues, so we do not want to add to those nor add support for rabbit-holes that users could easily get themselves into.
If you want to use a TS transformer yourself, I think overriding the Rollup config in tsdx.config.js is an appropriate route and gives the appropriate appearance as potentially brittle and somewhat hacky; as opposed to a problematic, but officially supported API.
On that note, I'll be hiding your comment as I think it has a lot of potential to confuse users.

So, my question here we'll be: can you add support for transformers for this plugin? I'know it's not a stable api on the plugin( they said it already, this was created before the plugins support on ts), but it seems they're not ready yet to fully support the native behavior. In the meanwhile, this solves the issue, and helps users to add custom plugins to typescript.

I have not confirmed the fix myself, but as I wrote above, there's a much much simpler way to solve the issue and I'm focused on the root cause as opposed to adding increasingly messier and more brittle workarounds that will cause added headaches to support.
I don't think we want to support TS transformers at this time, as not only are they an unstable API that isn't really supported, they are also not very compatible -- you'd need to add support in tsdx test and tsdx lint, tsc --noEmit, VSCode plugins, etc, etc, etc. Compatibility issues are some of the most popular TSDX issues, so we do not want to add to those nor add support for rabbit-holes that users could easily get themselves into.
If you want to use a TS transformer yourself, I think overriding the Rollup config in tsdx.config.js is an appropriate route and gives the appropriate appearance as potentially brittle and somewhat hacky; as opposed to a problematic, but officially supported API.
On that note, I'll be hiding your comment as I think it has a lot of potential to confuse readers.

@agilgur5  I've done this workaround because of the fix you proposed was not working for me. I'm working with several libraries created with tsdx on a large monorepo and they all present the same issue, actually fixed for me at least with this workaround. I've passed two days browsing and trying any kind of fixes and only that one worked well on every library we have in the monorepo without any further modification.
I'm still pending results on this topic, if any other solution comes to light.

@ibraelillo well I'm not sure why it doesn't work for you, #488 has tests included and they pass. If something doesn't work, would need a minimal reproduction to ascertain anything. Though to be clear, the real fix and real issue is upstream and not here and that's where attention should be focused.

There's a winding web of issues here that are difficult to follow while attempting to ascertain who/how/if there is a fix for this. Shouldn't this be fixed by default without needing to use (or add) declarationDir? To me, declarationMap files are a major dx improvement that a tool like this would make certain were working out of the box.

@paynecodes to summarize:

Shouldn't this be fixed by default without needing to use (or add) declarationDir?

Using declarationDir is a workaround that so happens to solve the issue. This includes setting it to dist/.

I added the dist/ use by default in #488, however aside from being not a root cause fix, that option is actually breaking.
The useTsconfigDeclarationDir of rpts2 makes TS output the declarations instead of Rollup, which is why it fixes it. That can break downstream Rollup config via tsdx.config.js if anyone were relying on that to make further declaration transformations (e.g. #80)

To me, declarationMap files are a major dx improvement that a tool like this would make certain were working out of the box.

This is a bug upstream, not here. I filed https://github.com/ezolenko/rollup-plugin-typescript2/issues/204

The maintainer helped point out the bug, however changing that to be correct was infeasible due to how Rollup's plugin lifecycle worked
The repo/library itself is only partially maintained I would say; lot of unresolved or unresponded to issues that have been building up. There's only two alternatives and they have their differences too.

I eventually filed a PR to fix it upstream as well: https://github.com/ezolenko/rollup-plugin-typescript2/pull/221

This accounts for the lifecycle issue above, and I had to dive fairly deep into the codebase (which is not the simplest) in order to understand this, as well as had to understand the Rollup plugin lifecycle.
That stalled and I was given a not very helpful response from the maintainer saying it broke something without any further guidance
I looked into it periodically March - May/June-ish and tested a lot of things to no avail. This was originally slated to be fixed for v0.13.x as the milestone I added here says.

That said, I had to explore more of the codebase so I'm more familiar with it now (including exploring #725 ), so I have an idea of how to fix it (and potentially deprecate and make useTsconfigDeclarationDir no longer necessary), but I need time to work that out and test it.

Neither this nor #490 have much up-votes, and most people don't know what declarationMaps even are, so the need / complexity ratio is pretty low in terms of prioritizing this.

@agilgur5 Thank you for your insightful reponse! If only more people know about declarationMap, I don't think think they would want to work without it. At least not in a monorepo context ;)

Just updated my PR upstream in https://github.com/ezolenko/rollup-plugin-typescript2/pull/221, think I've solved the problem now. Summarized a lot of the work and debugging I did in the comments there (https://github.com/ezolenko/rollup-plugin-typescript2/pull/221#issuecomment-701119370)


Add allocation info block to pool allocator

Would be best to know PoolAllocator:

chunkSize
chunkCount
freeChunksCount

so I need to add additional memory chunk with PoolAllocator info before memory pool itself.
and
Would be best to track each PoolAllocator allocation/deallocation request to save those properties on Debug configuration:

allocation/deallocation request line
allocation/deallocation request file

It would be super good to move my prototype using ObjectAllocationInfo struct to AllocationInfoBlock implementation for each allocation.
ObjectAllocationInfo contains this data:
struct ObjectAllocationInfo
	{
		uint8* base;
		size_t allocationSize;

		uint8* object;
		size_t objectSize;
	};

I would like AllocationInfoBlock to have information that I would nevertheless allocate on heap for each allocation. But it needs to be optimized as I will allocate it before each allocated pool/object
objectSize and objectPtr are must have.
I need to design it properly.


Rewrite readme mixin example to use Higher Order Component

Hello, I see the readme demonstrates how to build a form element. However it utilizes the mixins field.
Now that mixins are considered harmful would a rewrite of the example in the readme be welcome?

Ah, yes! This has been on my todo list for a long time.

@aesopwolf and @morenoh149 any progressive with this ? If not, I could help with this!

@Jareechang I'd submit a quick PR and link here a gist. I'm sure 20 other folks would appreciate it even if the maintainers choose never to change the readme. Sadly I've lost the context I had when I opened this issue :p

@morenoh149, ok. I'll go ahead and do that.
up to date documentation / examples = ❤  for developers!

@Jareechang I haven't made an progress with this. I'll gladly accept a PR though!

With the announced changes in v16 this will become a more pressing topic https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html

Sorry for being late on this one. I am currently updating the DOCS and examples with new syntax which hopefully would help! PR coming soon, stay tuned peeps!

if anyone is interested is still stuck on how to convert away from using mixins, see my PR at #449. It provides an example of this. Feel free to reach out to me if you are stuck.

This issue has been SOLVED in the new formsy organization with Formsy 1.0.1: https://github.com/formsy/formsy-react/issues/2


Something is wrong here...


How to filter Thread Dump in sanitization?

I want to still appearing thread name in Thread Dump block after i run this tool, But now all of thread names are sanitized as below.
Has any idea for retain them?
Thanks for your help.

@maxxedev Hi, Max, do you have any idea for fix it? You can tell me your thinking or idea, i can help you to fix it

Basically the tool needs to keep track of all the threads and their thread name fields. Something like:

scan the heap dump for java.lang.Thread object ids, keep track of the thread name object ids
scan the heap dump for java.lang.String objects. keep track of strings that match thread name object ids
when sanitizing strings, skip if the string object id matches one of thread name object ids.

It's doable but a bit complicated.

Another option is to simply capture a thread dump (e.g. with jstack, jcmd) when capturing a heap dump. Not quite the same as the threads in heap dump but should be accurate enough. In fact, if you run the tool with docker option as mentioned in README, the tool will create both thread dump and heap dump files

Hi Max, thanks for your reply.
Actually, I have though about use jstack or jcmd for capture a thread dump, there is suitable for normal scence.
But not suitable for exception scene , such as can not suitable for OOM.


juju_application and juju_unit labels are incorrect and confusing

Bug Description
I suspect that this issue was caused by https://github.com/canonical/cos-proxy-operator/pull/120 and other related patches.
When using cos-proxy rev 74, juju_application shows incorrect/confusing labels, for example:

nagios context in nrpe is set to bootstack-blue
hostname is abc1-cloud-node-5
application name is nova-compute-kvm
unit name is nova-compute-kvm/2

The expected labels and the previous behaviour of cos-proxy are:

juju_unit="nova-compute-kvm/2"
juju_application="nova-compute-kvm"

In the recent versions of cos-proxy it became:

juju_unit="bootstack-blue-abc1-cloud-node/5"
juju_application="bootstack-blue-abc1-cloud-node"

Neither is correct since such a Juju application and unit don't exist.
The charm seems to make an incorrect assumption that the hostname always matches the juju unit name which almost never happens.
To Reproduce

Deploy cos-proxy rev 74.
Deploy ch:ubuntu as ubuntu app to a VM with its hostname set to abc-123.
Deploy nrpe charm as a subordinate to ubuntu. Set any nagios_context.
Set up monitors relation, relate cos-proxy to COS as always.
In prometheus and alertmanager, the juju_application and juju_units labels will show <nagios_context>-abc and abc/123 incorrectly.

Environment
cos-proxy rev 74, other versions shouldn't matter
Relevant log output
None, the labels in Prometheus/Alertmanager are incorrect.

Additional context
No response

This should be rolled back to the previous behaviour. Hostname should be a separate label.

According to @przemeklal, rev 54 behaves differently, "more correctly", and that in rev 71 the labels are already "wrong".
@przemeklal also noted that if the hostnames don't follow the "abc-123" pattern but something like to a-abc123 (i.e. do not end with - and number), then both juju_application and juju_unit labels are identical and equal to the hostname.
Inspecting the rev54...rev71 diff, I see no functional difference for lib/charms/nrpe_exporter/v0/nrpe_exporter.py.

To reproduce
Relation view
flowchart LR

subgraph VM model
nova-compute-kvm --- nrpe --- cos-proxy
end

subgraph COS
prometheus
end

cos-proxy --- prometheus

Machine view
graph TD

subgraph "Machine: some-nice-hostname"

subgraph "Subordinates"
nrpe/0
end

nrpe/0 --- cos-proxy/0
nova-compute-kvm/2 --- nrpe/0

end

I wonder if this is because multiple charms are deployed on the same machine (juju deploy --to). I would compare labels to when the machine is named after the charm, and cos-proxy is in its own vm.

Somewhat related: https://github.com/canonical/grafana-agent-operator/pull/63

Well, seems I've found the issue....
I have the following deployment:

With the following config in nrpe:
juju config nrpe nagios_host_context="bootstack-blue"

Once every relation is in place, I can see in Prometheus:

We have a bug in the way we create the relabels_config list:
                "relabel_configs": [
                    {"source_labels": ["__address__"], "target_label": "__param_target"},
                    {"source_labels": ["__param_target"], "target_label": "instance"},
                    {"source_labels": ["__param_command"], "target_label": "command"},
                    {
                        "target_label": "__address__",
                        "replacement": "{}:9275".format(exporter_address),
                    },
                    {
                        "target_label": "juju_unit",
                        # Turn sql-foo-0 or redis_bar_1 into sql-foo/0 or redis-bar/1
                        "replacement": re.sub(r"^(.*?)[-_](\d+)$", r"\1/\2", id.replace("_", "-")),
                    },
                ],

The problem is that we relabel the juju_unit by using the target-id that is stored in the relation data by the nrpe charm. Besides, the nrpe charm concatenates the unit name with the nagios_host_context
(Pdb) relation.data
{..., 'target-id': 'bootstack-blue-nova-compute-kvm-0'}, <ops.model.Application nrpe>: {}}

that's why juju_unit label ends up being bootstack-blue-nova-compute-kvm/0
At this point we should:

Figure out a way to get the unit.name from bootstack-blue-nova-compute-kvm/0
Add a new relabel config for juju_application.

Hi @peppepetra
Do you think is it possible to add nagios_host_context as a field in nrpe relation databag so we can use it to discover juju_application and juju_unit??


surround-delete / surround-change don't work when point is at the surrounding

For example given the text (foo). When the point is at the opening brace and I call surround-delete or surround-change, I only get a message: surround--find-char-nestable: Did not find (
This is true for (, [ and {, but it does work for " and '.

Thanks for reporting.  I'm not sure how I hadn't noticed - I guess I'm usually deep in a set when I need this.

Yes, it works, thank you very much!


Fixed #25389 -- Fixed pickling a SimpleLazyObject wrapping a model.

Pickling a SimpleLazyObject wrapping a model did not work correctly; in
particular it did not add the _django_version attribute added in 42736ac8.
Now it will handle this and other custom __reduce__ methods correctly.
Also added a regression test.

buildbot, test this please.

An alternate implementation seems to be: https://github.com/django/django/pull/5337. Would you mind discussing the best implementation with that author?

I'm sure this fix is better way to go. I was worried about touching "dict" but this becomes another issue when @benjaminjkraft's fix is shipped. I'd rather create another ticket where my fix becomes necessary :)

Could you add release notes for 1.8.5? I'll admit, pickling isn't my expertise. Are you fairly confident this won't cause other regressions?

This fix is nice if you plan to ship it on 1.8.5 because it solves the issue without messing with actual model class which could possibly result in pickling error due to change in model class while pickling.

I can do that.  I'm reasonably confident that this works in all the same cases as the old implementation, at least; it should be the same behavior in cases where __reduce__ is not overridden, and the tests work in a number of configurations on each pickle version in both python 2 and python.  And I do think it's worth backporting if possible, because as @knifenomad's ticket points out, you don't have to do crazy things with __dict__ to make this an error rather than just a warning or missing safety check -- you just have to have a OneToOneField, so this could be hit by any site that has a profile model attached to users and tries to pickle request.user.
Do you prefer that I push a second commit to this branch with the fix, force-push to this branch, or make a new branch with the fixes?

Force pushing the changes here is preferred. Thank you.

I'd like to release 1.8.5 this week, please let me know if you'll have time to update this patch for that release.

I looked at this a bit tonight, and ran into another issue.  I think I finally understand what's going on, but I need to think through the implications and potential fixes some more.  I'll take another look tomorrow evening.

Okay, I've pushed a fix to the issue I discovered while adding further tests.  (In particular, the case of a model with a OneToOneField was still raising the version check warning on unpickling.  This was roughly because to pickle it looked like there were two objects floating around with)  Now instead of trying to impersonate the wrapped object to be pickled, we simply use a custom unpickler with a single argument, namely the wrapped object, which returns that object.  This avoids the issue by having pickle pickle the wrapped object entirely normally (as an argument to the unpickler).
Pickling a SimpleLazyObject before this change and unpickling it after should work just fine.  (I tested this manually just to check, since writing an automated test for it would be tricky.)  The reverse (pickling an object after this change, and unpickling it before) won't work, but I think that's unavoidable in the bug fix.  If you really want to avoid that in a point release, I can make a version for 1.8.5 which does a partial fix (basically just the original version of this patch, which will fix the errors but will still cause warnings in some cases) and does not prevent sending pickles to old versions, and keep this in 1.9 and master.  It seems unnecessary to me, but I'm happy to do things either way.
That's the only potential issue I can think of.  I've added some extra tests using actual models, to better catch future regressions.  Lastly, I added a line to the release notes.  Let me know if there's anything else I can do!

(fixed the lsort issue)

buildbot, add to whitelist.

merged in 35355a4ffedb2aeed52d5fe3034380ffc6a438db, thanks!


Have you worked out any other diasend endpoints?

Hey,
I am working on some stuff related to diasend and found very little information. I have as well been able to pull down the patient/data but am looking for the endpoint that exposes the pump settings and have had little luck. Have you found anything useful about the API endpoints?

Currently: CamAPS --> Diasend
Soonish: CamAPS --> Dexcom Follow (which is not Dexcom Share? Dexcom Share can send all data to Diasend (https://international.diasend.com/patient/account/apps).
Long term: CamAPS will move from Diasend to the new Glooko environment, which will should have API access, so I'm told.
I try to use Nightscout as my main data portal, so everything needs to end up in there. Currently xDrip+ sends BGL from CamAPS and our Caresense Dual blood readings to Nightscout.

I have as well been able to pull down the patient/data but am looking for the endpoint that exposes the pump settings and have had little luck. Have you found anything useful about the API endpoints?

From my attempts to reverse-engineer the API due to the lack of any available documentation, it appears that there are no endpoints exposing the information you're looking for. The API that exists appears to have been tailor-made for the diasend app (which also doesn't offer the data you're looking for). So the only way to obtain that data to my knowledge would be to scrape the diasend website or use their export functionality.
Personally, I am planning to extend this project to import all available data from diasend to nightscout, not just the CGM values, but haven't yet spent a lot of time experimenting on getting that data.

Soonish: CamAPS --> Dexcom Follow (which is not Dexcom Share? Dexcom Share can send all data to Diasend (https://international.diasend.com/patient/account/apps).

That sounds like quite an improvement already since Dexcom (Folllow) at least appears to offer some APIs to get the data (but naturally, those will be focussed on CGM / BGL / EGV I assume?). Anyhow, is it already confirmed that the CamAPS team is working on that integration?

Long term: CamAPS will move from Diasend to the new Glooko environment, which will should have API access, so I'm told.

Do you have any information what long-term means? I am fairly new to the whole T1D world but I assume it could take years?

I try to use Nightscout as my main data portal, so everything needs to end up in there. Currently xDrip+ sends BGL from CamAPS and our Caresense Dual blood readings to Nightscout.

I've just recently found out about xDrip+ being able to pull the CGM data from CamAPS directly (thanks @grahamjenson ) but haven't tried it out personally yet. Does it also support pulling other data apart from the BGL values?
E.g. one issue I'm having with diasend right now is that it doesn't provide information about the BGL trend (up, down, steady, ...) since I guess it's goal is more on the side of historial reports than on the real-time monitoring.

Unfortunatly xDrip pulling from CamAPS is a giant hack, so will not be able to support pulling any other data like insulin. How it works is it listens to the notifications that CamAPS publshes to the Android hopmescreen, then xDrip parses that notification (very manually) to extract the data. This is super jank, so can result in missed and incorrect readings.
I also did a bit more deep dive into diasend via. CamAPS, it seems that the other data (pump settings...) are uploaded to diasend via S3, so not very useful. I did find an enpoint https://api.diasend.com/1/patient/setting which seems active but I am just getting errors from. Perhaps to read it I need a different oAuth scope or something.
I have seen a few CamAPS docs that state they are working on sending their data to Dexcom directly, which has clarity (IMHO better than diasend). AFAIK all these integrations take years, or become vaporware which never happen, so waiting is not the best option.

That sounds like quite an improvement already since Dexcom (Folllow) at least appears to offer some APIs to get the data (but naturally, those will be focussed on CGM / BGL / EGV I assume?). Anyhow, is it already confirmed that the CamAPS team is working on that integration?

The delay I am told is only on the Dexcom side, implementation is finished, but Dexcom needs to turn it on.
Do you have any information what long-term means? I am fairly new to the whole T1D world but I assume it could take years?
End of the year.

I try to use Nightscout as my main data portal, so everything needs to end up in there. Currently xDrip+ sends BGL from CamAPS and our Caresense Dual blood readings to Nightscout.

Xdrip Does it also support pulling other data apart from the BGL values?
Nope, only BGL values, without backfill, so sometimes you get gaps.

I have as well been able to pull down the patient/data but am looking for the endpoint that exposes the pump settings and have had little luck. Have you found anything useful about the API endpoints?

So the only way to obtain that data to my knowledge would be to scrape the diasend website or use their export functionality.

I found some time today to do some scraping and put together some code to pull down the basal profile from the diasend website due to the lack of a proper API. It should be fairly simple to also scrape any other data of interest from there.
@grahamjenson You can check it out and see if that does what you need.

Update: v0.5.0 of this library supports obtaining the pump settings from diasend website like:
import { getPumpSettings, getAuthenticatedScrapingClient } from "./diasend";

const username =<EMAIL_ADDRESS>const password = "super-secret-password";

const { client, userId } = await getAuthenticatedScrapingClient({
  username, password
});

console.log(await getPumpSettings(client, userId));

yields
{
  "basalProfile": [
    ["00:00", 0.5],
    ["06:00", 1.0],
    ["12:00", 0.3],
    ["16:30", 0,7]
  ],
  "insulinCarbRatioProfile": [
    ["00:00", 20],
    ["06:00", 10],
    ["12:00", 15],
    ["16:30", 20]
  ],
  "insulinSensitivityProfile": [
    ["00:00", 350]
  ],
  "bloodGlucoseTargetLow": 70,
  "bloodGlucoseTargetHigh": 160,
  "insulinOnBoardDurationHours": 3,
  "units": "mg/dl",

Just forked your cgm-remote-monitoring repo and deployed it to heroku - import from diasend works out of the box --> THANK YOU - Great Work!
... but I do have a timestamp issue. Imported data is postponed 2h.
Bolus from 7.35 on diasend is on 9.35 on nightscout. I will check my config at heruko and diasend and report back.

Just forked your cgm-remote-monitoring repo and deployed it to heroku - import from diasend works out of the box --> THANK YOU - Great Work! ... but I do have a timestamp issue. Imported data is postponed 2h. Bolus from 7.35 on diasend is on 9.35 on nightscout. I will check my config at heruko and diasend and report back.

Yeah, that's kind of a known issue and was raised already here. The workaround right now is to make sure that the TZ is correctly set on your nightscout instance (on heroku). Should be set to the same timezone you're in. Diasend sadly doesn't tell us what timezone the data is in, so the data is just considered to be in the timezone the nightscout instance operates in (which by default is UTC). If you're in Germany, set TZ=Europe/Berlin and you should be fine.

Closing this due to the original question being answered. Feel free to open a new issue if you have some follow-up questions


Fix burgerMenu

Hi friend, congrats for this project.
burgerMenu button not working properly on mobile or small breakpoints
https://github.com/user-attachments/assets/b131e98c-930b-4fc6-9d98-68e2b7daad07
After the small fix
https://github.com/user-attachments/assets/aeee1d1f-9233-4357-a7fb-64d5a5158663

Thanks for the fix


FPS error without cam

Without cam section in config i get

Printer online
Config errors in section [camera]:
Option 'fps: 0': value is not above 0
Please correct the configuration according to the wiki (https://github.com/nlef/moonraker-telegram-bot/wiki/Sample-config)

at startup

Disabling camera section should disable parameter checks.
Functionality needs to be tested again.

Has been fixed on dev


Update server installation documentation (#5982)

Pull request opened by the merge tool on behalf of #5982

Merged into branches iso6 in ad9fafb4b33797f24ea3a8913e7202b5c39f5f31


changing import to github.com/swaggest/swgen to make fork go gettable

Sorry, wrong PR 😳

Coverage decreased (-1.3%) to 89.75% when pulling 91e5d984540c1e9a7687e9cbab052bb92d2a50f6 on swaggest:forking-import into 52757e1a1d14f4b42dfc5d50abe654b69cf882dd on lazada:master.

You are forgiven ;)
On Tue, Jun 19, 2018 at 5:30 PM Viacheslav Poturaev <
<EMAIL_ADDRESS>wrote:

Sorry, wrong PR 😳
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lazada/swgen/pull/28#issuecomment-398336312, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABqQAVht4HwkK-4QKFaHlY9lghzXIAVwks5t-MSlgaJpZM4UtJ69
.


API Key: undefined

Hi, I can't generate a new api key.

Hi @abr4xas apologies i completely missed this. Did you get this resolved?

Hi @robjpope yes, thanks!!


Remove the Google index blocking

Description:
Remove the NO FOLLOW line below in the base.html file when the site is ready to be published live.
<meta name="robots" content="noindex">
Suggested Labels:

Suggested Assignees:

Affected Product Version:
OS, DB, other environment details and versions:
Steps to reproduce:
Related Issues:

Will be fixed via https://github.com/wso2/docs-ballerina-vscode-extension/pull/133.

Done via https://github.com/wso2/docs-ballerina-vscode-extension/pull/133.


Enabled base infrastructure for Hardware Isolation (aka Guard) feature

In this PR enabled base infrastructure for Hardware Isolation (aka Guard).
Please refer design document:
https://github.com/openbmc/docs/blob/master/designs/guard-on-bmc.md
DBus interfaces:
https://gerrit.openbmc-project.xyz/q/topic:%2522hardware-isolation%2522+(status:open+AND+-is:wip+OR+status:merged+AND+project:openbmc/phosphor-dbus-interfaces)

Looks good to me

This needs to be rebased and put against 1020 branch.

Looks good to me.. not able to approve


To Reproduce

Hello,
I really appreciate your retrieval-based detection method, it is very concise and effective. I was wondering if you could provide more details in the README file to make it easier to reproduce, such as the dataset address, processing flow, pre-trained paraphraser weights, and necessary steps for implementing paraphrase attacks and using the retrieval-based method for defense. Thank you very much!

Hi @jc-ryan,
Thanks for your interest in our work! We are still waiting for a final approval for our model release, which we expect later this week. Once I have that, I will upload the model link, clean up the README / repository, upload the data to Google Drive. Sorry for the delay!

Hi @jc-ryan, Thanks for your interest in our work! We are still waiting for a final approval for our model release, which we expect later this week. Once I have that, I will upload the model link, clean up the README / repository, upload the data to Google Drive. Sorry for the delay!

Thanks for the information, looking forward to it~

Hi @jc-ryan, please email me if you want quicker access to the model (kalpesh@cs.umass.edu). I'm expecting the official release will take 2 more weeks minimum.

We've updated the README.md file with the model checkpoints, thanks for your patience!


[Adaptive] Should prompt user invalid datetime for datetimeinput

Datetimeinput samples

user input correct datetime , the value will be set correctly
then user input invalid datetime "eg. hi", the value will be set to the previous ones ( successful setting). This is not correct.

Please provide how to reproduce it.

@hibrenda The invalid prompt is "Please enter a date" which is same as the initial prompt. So maybe we should change the text of invalid prompt, or change the max turn count?

So the problem is, if the user set alwaysprompt, should we clear the property? @vishwacsena
This issue is caused that, we set alwaysprompt and after the maxturn is reached, it will use the previous property value.

@Stevenic, @tomlm I can repro this issue and I believe always prompt should clear the property for it to be more predictable especially in the interplay with maxTurnCount set.
var rootDialog = new AdaptiveDialog(nameof(AdaptiveDialog))
{
    Generator = new TemplateEngineLanguageGenerator(),
    Rules = new List<IRule> ()
    {
        new UnknownIntentRule()
        {
            Steps = new List<IDialog>()
            {
                new NumberInput() {
                    Property = "user.age",
                    AlwaysPrompt = true,
                    Prompt = new ActivityTemplate("Give me your age"),
                    MaxTurnCount = 2
                },
                new IfCondition() {
                    Condition = "exists(user.age)",
                    Steps = new List<IDialog>() {
                        new SendActivity("Your age is {user.age}"),
                    },
                    ElseSteps = new List<IDialog>() {
                        new SendActivity("I do not have your age"),
                    }
                },
                new RepeatDialog()
            }
        }
    }
};

With this snippet, if you try the following, you will see the error - the bot should not have continued to use 46 from the prior response from user especially when alwaysPrompt is set.
user: hi
bot: give me your age
user: 46
bot: Your age is 46
bot: give me your age
user: hi
bot: give me your age
user: hi
bot: Your age is 46     <--- I believe this is incorrect.


Validation error after upgrade from 0.3.7 [bug]

Describe the bug
I am running into an issue when deploying after upgrading from 0.3.7 to 0.3.8 or 0.3.11. Deployment succeeds if I revert the version change. I am running this using gitlab integration and the following error occurs:
qhub deploy --config qhub-config.yaml --disable-prompt --skip-remote-state-provision
Problem encountered: 1 validation error for Main
default_images -> dask_gateway
  field required (type=value_error.missing)

I can reproduce the error locally by using qhub validate (and using pdb to drop in to the call stack). It seems like pydantic isn't happy with something. I don't know whether the schema changed or the way pydantic is called.
(Pdb++) Main(**config)
*** pydantic.error_wrappers.ValidationError: 1 validation error for Main
default_images -> dask_gateway
  field required (type=value_error.missing)
Traceback (most recent call last):
  File "pydantic/main.py", line 400, in pydantic.main.BaseModel.__init__
(Pdb++)

Any guidance in how to delve deeper/interpret the traceback would be appreciated.

I think you might fix this following this comment by @costrouc:

We had to build our own version of dask gateway (which is currently a small PR at dask-gateway waiting to be merged). There are also docs on upgrades https://docs.qhub.dev/en/latest/source/02_get_started/08_upgrade.html. There is a new dask_gateway key detailed in the docs https://docs.qhub.dev/en/latest/source/02_get_started/04_configuration.html#default-images.

Yeup exactly thanks @brl0! @leej3 let me know if adding the dask_gateway key to default-images works for you. It is here in the docs https://docs.qhub.dev/en/latest/source/02_get_started/04_configuration.html#default-images


Fix creating subscription cache in method 'on'

Subscription cache always fills with all subscribers

on: function( topic, callback ) {
	var self = this;
	self._subscriptions = self._subscriptions || {};
	self._subscriptions[ topic ] = self._subscriptions[ topic ] || [];
	var subDef = new SubscriptionDefinition( topic, callback, self );
	self._subscriptions[ topic ].push( subDef );

	// Next, add the SubscriptionDefinition to any relevant existing cache(s)
	_.each( self._cache, function( list ) {
	// subDef.topic === topic here, because  subDef was created for this topic
		getCacher( topic, list )( subDef );
	} );

	return self._subscriptions[ topic ][ self._subscriptions[ topic ].length - 1 ];
},

@artemkaint Sincere apologies for this slipping through the cracks! I ran into this on my own as well and fixed it recently. Latest version (v0.3.3) shouldn't have this problem any longer.


[FEATURE] Save an evolved_estimator?

How can I save an evolved_estimator into a file and read it?

Hi, you can use any Python serializer method, for example, joblib.dump, it should be something like:
from joblib import dump

dump(evolved_estimator , 'evolved_estimator.pkl')

Hi, you can use any Python serializer method, for example, joblib.dump, it should be something like:
from joblib import dump

dump(evolved_estimator , 'evolved_estimator.pkl')

It's not working:
Traceback (most recent call last):
  File "/home/txxie/code/AnxietyPred/feature_selection.py", line 65, in <module>
    main()
  File "/home/txxie/code/AnxietyPred/feature_selection.py", line 50, in main
    dump(evolved_estimator, "evolved_estimator.test.pkl")
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/site-packages/joblib/numpy_pickle.py", line 553, in dump
    NumpyPickler(f, protocol=protocol).dump(value)
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/pickle.py", line 487, in dump
    self.save(obj)
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/site-packages/joblib/numpy_pickle.py", line 355, in save
    return Pickler.save(self, obj)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/pickle.py", line 603, in save
    self.save_reduce(obj=obj, *rv)
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/pickle.py", line 717, in save_reduce
    save(state)
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/site-packages/joblib/numpy_pickle.py", line 355, in save
    return Pickler.save(self, obj)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/pickle.py", line 560, in save
    f(self, obj)  # Call unbound method with explicit self
    ^^^^^^^^^^^^
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/pickle.py", line 972, in save_dict
    self._batch_setitems(obj.items())
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/pickle.py", line 998, in _batch_setitems
    save(v)
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/site-packages/joblib/numpy_pickle.py", line 355, in save
    return Pickler.save(self, obj)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/txxie/software/anaconda3/envs/anxiety/lib/python3.11/pickle.py", line 578, in save
    rv = reduce(self.proto)
         ^^^^^^^^^^^^^^^^^^
TypeError: cannot pickle 'module' object

Here is my code, modified from the feature selection sample:
X, y = load_data("Data", frame_wise=True)  # (n_videos*n_frames, 1)
    X_train, X_test, y_train, y_test = train_test_split(
        X, y, test_size=0.1, random_state=0
    )
    X_train = X_train[:1000, :]
    y_train = y_train[:1000]
    X_test = X_test[:100, :]
    y_test = y_test[:100]

    print(f"[X train] shape: {X_train.shape}, [y train] shape: {y_train.shape}")
    print(f"[X test] shape: {X_test.shape}, [y test] shape: {y_test.shape}")

    # pipline = Pipeline(
    #     (("scaler", StandardScaler()), ("linear_svc", LinearSVC(loss="hinge")))
    # )
    # pipline = Pipeline((("scaler", StandardScaler()), ("svc", SVC(gamma="auto"))))
    model = SVC(gamma="auto")

    mutation_scheduler = ExponentialAdapter(0.8, 0.2, 0.01)
    crossover_scheduler = ExponentialAdapter(0.2, 0.8, 0.01)

    evolved_estimator = GAFeatureSelectionCV(
        estimator=model,
        scoring="accuracy",
        population_size=100,
        generations=200,
        mutation_probability=mutation_scheduler,
        crossover_probability=crossover_scheduler,
        n_jobs=-1,
    )

    # Train and select the features
    callbacks = [TensorBoard(log_dir="./logs")]
    # evolved_estimator.fit(X_train, y_train, callbacks=callbacks)

    dump(evolved_estimator, "evolved_estimator.test.pkl")

    # Features selected by the algorithm
    features = evolved_estimator.support_
    print(features)

    # Predict only with the subset of selected features
    y_predict_ga = evolved_estimator.predict(X_test)
    print(accuracy_score(y_test, y_predict_ga))
    print(confusion_matrix(y_test, y_predict_ga))
    # Transform the original data to the selected features
    X_reduced = evolved_estimator.transform(X_test)


Syntax definition missing end-of-line non-terminal

.LIST ;;
;; ::= (;[\x00-\xFF^\x10]*)?\x10

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

ID: f92aa18b-e133-8d5e-36ae-651432d2d08e
Version Independent ID: d289ff82-211a-b0de-f28f-65c1410f2577
Content: .LIST
Content Source: docs/assembler/masm/dot-list.md
Product: visual-cpp
Technology: cpp-masm
GitHub Login: @corob-msft
Microsoft Alias: corob

Incorporated into Incomplete Syntax definition issue.

@Player1UK thanks! See comment for #1123.


libunistring: 0.9.6 -> 0.9.7

Motivation for this change
Things done

[X] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[X] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

See http://lists.gnu.org/archive/html/info-gnu/2016-12/msg00002.html for announcement

Hrmm... can you find a changelog on this?

Ah, nevermind, I missed it for being so short:
New in 0.9.7:

The license has changed from LGPLv3+ to "LGPLv3+ or GPLv2"


gpio bidings done

solves #14

It the implementation using a library (rppal). see #6 to understand;

From what I see, this PR is just a part of another PR, so it will be better not to squash and merge this one, but the other one instead


Known issue: MultipleChoiceQuestion won't change after an edit

When editing the question, the answers won't change (until a reload).

Should be resolved beforce the release

Solution:
Own Question Model - internal update with observables


JSDoc Inteli-sense quirks for namepath tildes and @scoped module names

VSCode Version: 1.33.1
OS Version: MacOS 10.14.4

It seems that the tilde (~) JSDoc namepath character gets parsed as a strikethrough when two of them wrap words.  Also @scoped module names seem to get parsed unique JSDoc entities. For example, this gets generated:

From:

Seems to parse fine with other consumers like jsdoc-to-markdown.
Steps to Reproduce:

Include a full JSDoc namepath with two tildes wrapping words and a scoped namespace for the module.

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

Please share the text of the code along with screenshots

No problem, sorry about that.
That function has the following JSDoc:
  /**
   * Add a Websocket listener at a specified path
   * @param {object|string} [options] Websocket configuration options
   * @param {string} [options.path=/] Path to offer Websocket at
   * @param {boolean} [options.parseJson=false] Automatically JSON message bodies
   * @param {string} [options.logName] NodeFuel log name/id to use
   * @param {string} [options.logLabel] NodeFuel log label to use
   * @returns {module:@nodefuel/web~Webserver~wsServer} Websocket server object
   */
  addWebsocket(options='/') {
...

With that return referencing something that is defined in an @typedef. Not sure if that matters.
    /**
     * A Websocket service endpoint (extends WS Server instance)
     * @typedef {object} module:@nodefuel/web~Webserver~wsServer
     */

Opened https://github.com/microsoft/TypeScript/issues/31298 to track root cause of this upstream


Command pools should have a better API

Right now you have to manually call free. An RAII solution would be preferred.
However this needs some reworking because it's tedious to link an allocated command buffer to its pool.

Fixed in #444


Add AOE questions to FHIR conversions

Description
AOE questions need to be included in the FHIR bundle we send to report stream.
Proposed solution
Each AOE question should have it's own observation added to the bundle
Additional context

closing as duplicate of #5271


Support multiple @static attributes

Fixes #1099. Couple of things that need to be addressed:

[x] compile-invoke should fail if a primitive has more than one @go-@done interface.
[ ] group2invoke needs to be reason about multiple @go-@done specs being present.
[ ] Add test with multiple specs
[x] Change the existing primitives to use the new syntax for static and make it a validate error to place static on component or primitive definitions themselves.

Extremely cool; nice work on this so far!! I'm glad we're making a clean break with the monolithic per-component version of the annotation.

This is blocked on #1093


update teamcity docs for openmetrics

What does this PR do?
update openmetrics example
Motivation
https://datadoghq.atlassian.net/browse/AGENT-12910
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Add the qa/skip-qa label if the PR doesn't need to be tested during QA.
[ ] If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

/merge

/merge -c


[Request]: Update notice regarding 120 FPS for Star Rail

Is your request related to a problem?
No
How is the feature request related to the problem?
No response
Describe your proposed solution

In short, Graphics Settings menu no longer breaks when using 120 FPS via registry edit. It will just display the option as 30 FPS.
Changing other graphic options also will NOT reset FPS back to 60 or lower. It will only reset when you actually change the FPS option itself.
Everything else works fine, including pressing Esc on keyboard to exit the settings menu, as if nothing breaks really.
Describe alternatives you've considered
N/A
Additional context
It looks like this was already noticed since v2.1 update, but I only found out today. Graphics Settings menu being inaccessible was too annoying for me, so I just coped with 60 FPS, hence why I never noticed.

Heyo, the text was updated in 696b735. This should be pushed in the next release of Collapse Preview. Thanks for your report!

An update that include this fix already been published on 1.80.5, we'll close this issue ticket.
If you have any problem, don't hesitate to reopen this or make a new ticket.
Thank you for using Collapse Launcher <3


Fix incorrect textproto syntax in metadata.

 * (M) tools/wikidoc/wikidoc.go
   - Make wikidoc report what file it failed to parse.
 * (M) feature/bgp/policybase/otg_tests/comm_match_action_test/metadata.textproto
 * (M) feature/bgp/policybase/otg_tests/extcomm_action_test/metadata.textproto
   - Fix missing [] to indicate a list of tags.

Pull Request Functional Test Report for #2764 / ed8fe45198800899443c04665b1d71329fbf9eee
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities
10e0e2d8
Log

Cisco 8000E

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities
4bf39d53
Log

Cisco XRd

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities
7dcefcc7
Log

Juniper ncPTX

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities
88f66e58
Log

Nokia SR Linux

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities
3e272d4f
Log

Openconfig Lemming

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities
88b03e73
Log

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities

Cisco 8808

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities

Juniper PTX10008

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities

Nokia 7250 IXR-10e

RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export PolicyRT-7.9: BGP Policy - Import/Export Policy Action Using Communities

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1730

Relevant Lines:
3262

💛  - Coveralls

Thanks for fixing this! I need to add a CI check for textproto syntax because this isn't the first time and the wiki generation was just the first thing to break.


Monokle validation remediation / help is unavailable

Monokle validation library offers extensive info and help for each error. In the Cloud it looks like:

while the extension tooltip only provides basic info:

And remediation part (which is Set 'set containers[].securityContext.allowPrivilegeEscalation' to 'false'. in this case) is not shown anywhere.
This is most likely SARIF-extension related.

Fixed in https://github.com/kubeshop/vscode-sarif/pull/3.


Doesn't report Read / Write access for current word under the cursor

Environment data

Language Server version: 2020.6.1
OS and version: Windows 10 Enterprise, Build 18363
Python version (& distribution if applicable, e.g. Anaconda): Python 3.8.3 64bit

Expected behaviour
According to https://code.visualstudio.com/api/references/theme-color#editor-colors, the language server should report read/write access for current variable (the word under the cursor), so that theme could assign them with different colors.
This is captured from the official documentation of VSCode.

This does work as expected if using old "Microsoft" language server.
As shown below, the variable "test" is under cursor, and it's write access so rendered as magenta, while the other occurrence of "test" is read access and rendered as blue.

It's magenta and blue because I configured this in my settings as below.

Actual behaviour
However, after switch to Pylance, it doesn't work any more. You would see both occurrences are rendered as green -- this is because language sever doesn't report the access type and it falls back to use the color defined for "selectionHighlightBackground" in my settings above.

Logs

[Info  - 4:49:07 PM] Pylance language server 2020.6.1 starting
[Info  - 4:49:07 PM] Server root directory: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server
[Info  - 4:52:00 PM] No configuration file found.
[Info  - 4:52:00 PM] Setting pythonPath for service "fda": "C:\Python\python.exe"
[Info  - 4:52:00 PM] stubPath c:\workspace\fda\typings is not a valid directory.
[Info  - 4:52:00 PM] Assuming Python version 3.8
[Info  - 4:52:00 PM] Assuming Python platform Windows
[Info  - 4:52:00 PM] Searching for source files
[Info  - 4:52:00 PM] Found 1 source file
[BG] analyzing: c:\workspace\fda\test.py ...
[BG]   parsing: c:\workspace\fda\test.py (18ms)
[BG]   parsing: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\2and3\builtins.pyi (470ms)
[BG]   binding: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\2and3\builtins.pyi (122ms)
[BG]   binding: c:\workspace\fda\test.py (1ms)
[BG]   checking: c:\workspace\fda\test.py ...
[BG]     parsing: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\3\typing.pyi (88ms)
[BG]     binding: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\3\typing.pyi (33ms)
[BG]     parsing: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\2and3\_typeshed\__init__.pyi (17ms)
[BG]     binding: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\2and3\_typeshed\__init__.pyi (2ms)
[BG]   checking: c:\workspace\fda\test.py (189ms)
[BG] analyzing: c:\workspace\fda\test.py (802ms)
[FG] parsing: c:\workspace\fda\test.py (47ms)
[FG] parsing: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\2and3\builtins.pyi (1031ms)
[FG] binding: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\2and3\builtins.pyi (293ms)
[FG] binding: c:\workspace\fda\test.py (5ms)
[FG] parsing: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\3\typing.pyi (165ms)
[FG] binding: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\3\typing.pyi (90ms)
[FG] parsing: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\2and3\_typeshed\__init__.pyi (29ms)
[FG] binding: c:\Users\jding4\.vscode\extensions\ms-python.vscode-pylance-2020.6.1\server\typeshed-fallback\stdlib\2and3\_typeshed\__init__.pyi (3ms

Code Snippet / Additional information

def f():
    test = "Write access for the variable"
    print(test, "Read access for the variable"

Looks like it is this LSP request which provides this information in MPLS, but is not supported yet in Pylance: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_documentHighlight

I implemented this support, and it will be included in an upcoming version of Pylance.

This issue has been fixed in version 2020.7.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#202070-9-july-2020


Update packages versions

Description
Updated all packages and tested if everything is working as we expecting. Hope that it helps to take the project up to date.

Checklist

[x] npm test passes
[x] npm run build works
[x] tests are included
[x] documentation is changed or added

@czystyl Thank you so much for the contribution 💯.


Add security policy to the project

Can you provide links to the security policy of other open source projects?


AttributeError: 'StatObject_SB' object has no attribute 'mean_stat_per_model'

I'm getting this error after running fast_PLDA_scoring.
scores_plda = fast_PLDA_scoring(enroll_xvectors_stat, test_xvectors_stat, ndx, plda.mean, plda.F, plda.Sigma)
print(scores_plda.scoremat.shape)

solved it, it seems mean_stat_per_model() is not implemented, so had to make sure there are no repeated enrollments.


detectLanguage isn't working

version: 0.7.2
snippet to reproduce:
import Foundation
import WhisperKit

Task {
  guard let desktopURL = FileManager.default.urls(
    for: .desktopDirectory,
    in: .userDomainMask
  ).first else { return }
  print("desktopURL: \(desktopURL)")

  let model = try await WhisperKit(model: "base")
  try await model.loadModels(prewarmMode: true)

  let fileURL = desktopURL.appendingPathComponent("0.wav")
  print("absoluteString: \(fileURL.path)")
  let (lang, langProbs) = try await model.detectLanguage(audioPath: fileURL.path)
  print("lang: \(lang), langProbs: \(langProbs)")
}

file: 0.wav.zip
tiny version gives:
lang: en, langProbs: ["en": -0.35910118]"

which is not all languages and has negative prob
base version gives:
[WhisperKit] Detected language nocaptions is not supported, defaulting to en
lang: en, langProbs: [:]

which is just plain error somewhere inside whisperkit

Thanks for the report!

The negative value is because it is a logProb value which has range [-inf,0]. To ease its usage, we should undo the log so you get [0,1]
The second issue is an edge case we should fix. When no speech is detected, the token that is supposed to signify the predicted language is not predicting a non0language token. Our TokenSupressFilter can fix this.

thanks
what about predicting multiple languages and corresponding probs?
why "no speech is detected"? audio example clearly has some :)

@ZachNagengast hi, is it on track to be completed anytime soon?

@stasbel This looks like it was actually a tiny oversight in the filter logic and not related to the sampling issues we just put out a fix for. Please check main with commit https://github.com/argmaxinc/WhisperKit/commit/c93d613c8c6fc3ec5b9d1d9da5d1f4206183c5e4 for the fix.

@stasbel Checking on this, is your issue resolved with the latest change?

Closing since this is an old issue, if it resurfaces, please reopen 🙏


feat: add HTTP api to interact with Manager

This PR adds an HTTP API implemented with FastAPI in front of the deployment Manager.
To run the server, from the llama_deploy folder:
python -m apiserver

To create a deployment:
curl -X POST -F<EMAIL_ADDRESS>http://localhost:4501/deployments/create/

@logan-markewich correct, we need a proper configuration system for the apiserver, likely just its own PydanticConfig object.


Fixes grpc server starving.

#224 introduced an RwLock. The grpc server potentially waited forever for write access, since the read lock wasn't released. This PR fixes this bug.

@wally-the-cartographer merge

Merge requested by authorized user feuerste. Merge queue now has a length of 1.


update prepare_variable

Codecov Report

Merging #119 (c1ade42) into master (8e0c028) will not change coverage.
The diff coverage is 80.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files

@@           Coverage Diff           @@
##           master     #119   +/-   ##
=======================================
  Coverage   79.63%   79.63%
=======================================
  Files          23       23
  Lines        1198     1198
=======================================
  Hits          954      954
  Misses        244      244

Flag
Coverage Δ

unittests
79.63% <80.00%> (ø)

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

Impacted Files
Coverage Δ

cordex/cmor/cmor.py
64.17% <80.00%> (ø)


save devtools zoom level preference

Fixes https://github.com/atom/electron/issues/2324
if its desired to maintain zoom level for all webcontent hosts then could setup preferences in BrowserContext::ZoomLevelDelegate::InitHostZoomMap , thoughts ?

if its desired to maintain zoom level for all webcontent hosts then could setup preferences in BrowserContext::ZoomLevelDelegate::InitHostZoomMap , thoughts ?

Only remembering zoom level for devtools is enough to me, other WebContents should be under users' full control.

Fixed, thanks!

:+1:


Visualizer is unresponsive for 20 seconds after selecting "Display > Show Only" on a muscle

Steps to reproduce

open Rajagopal2015 model
in Navigator, right-click Forces and select Display > Hide
expand Forces / Muscles / all
right-click "glmax1_r" and select Display > Show Only

Expected result
Muscle appears in Visualizer window essentially immediately.
Actual result
Visualizer window is unresponsive for ~20 seconds, then muscle appears. CPU usage spikes to 100%. The muscle appears after only ~2 seconds if Display > Show is selected instead.
Environment and GUI version
AppVeyor artifact OpenSim-d577f2dd-2018-05-29-win64.exe

Possibly a side effect of #802 (fix for #691).

Optimized code to render/refresh once at the end.

It isn't 20 seconds on my machine (with gait2392), but it is slower than I expect.


Error thrown by mergeocdpersonsbycontestandname

From this morning's update attempt on the dev server:
ERROR|03/Aug/2017 13:53:18|manage|Admin Command Error: /apps/calaccess/repo/manage.py updatedownloadswebsite --noinput --publish --verbosity=3
Traceback (most recent call last):
  File "/apps/calaccess/repo/manage.py", line 35, in <module>
    execute_from_command_line(sys.argv)
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/__init__.py", line 367, in execute_from_command_line
    utility.execute()
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/__init__.py", line 359, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/base.py", line 305, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/base.py", line 356, in execute
    output = self.handle(*args, **options)
  File "/apps/calaccess/repo/calaccess_website/management/commands/updatedownloadswebsite.py", line 37, in handle
    call_command('processcalaccessdata')
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/__init__.py", line 130, in call_command
    return command.execute(*args, **defaults)
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/base.py", line 356, in execute
    output = self.handle(*args, **options)
  File "/apps/calaccess/lib/python2.7/site-packages/calaccess_processed/management/commands/processcalaccessdata.py", line 64, in handle
    self.load()
  File "/apps/calaccess/lib/python2.7/site-packages/calaccess_processed/management/commands/processcalaccessdata.py", line 92, in load
    no_color=self.no_color,
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/__init__.py", line 130, in call_command
    return command.execute(*args, **defaults)
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/base.py", line 356, in execute
    output = self.handle(*args, **options)
  File "/apps/calaccess/lib/python2.7/site-packages/calaccess_processed/management/commands/loadocdelections.py", line 29, in handle
    self.load()
  File "/apps/calaccess/lib/python2.7/site-packages/calaccess_processed/management/commands/loadocdelections.py", line 89, in load
    call_command('mergeocdpersonsbycontestandname', **options)
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/__init__.py", line 130, in call_command
    return command.execute(*args, **defaults)
  File "/apps/calaccess/lib/python2.7/site-packages/django/core/management/base.py", line 356, in execute
    output = self.handle(*args, **options)
  File "/apps/calaccess/lib/python2.7/site-packages/calaccess_processed/management/commands/mergeocdpersonsbycontestandname.py", line 35, in handle
    self.handle_group(group_q)
  File "/apps/calaccess/lib/python2.7/site-packages/calaccess_processed/management/commands/mergeocdpersonsbycontestandname.py", line 143, in handle_group
    OCDPersonProxy.objects.merge([c.person for c in group_q.all()])
  File "/apps/calaccess/lib/python2.7/site-packages/calaccess_processed/models/proxies/opencivicdata/people.py", line 73, in merge
    merge(keep, i)
  File "/apps/calaccess/src/opencivicdata/opencivicdata/merge.py", line 128, in merge
    diff = compute_diff(obj1, obj2)
  File "/apps/calaccess/src/opencivicdata/opencivicdata/merge.py", line 22, in compute_diff
    raise ValueError('cannot merge object with itself')

This is the error that's popped here and there but we've never fully trapped. It seems to occur when mergeocdpersonsbycontestandname is used after the initial data load.

A little more detail...
Starting with empty OCD tables, I...

Called loadocdelections, which completed without throwing any errors.
Called mergeocdpersonsbycontestandname, which did not try to merge anyone and did not throw any errors.
I then called loadocdelections again, and this time the merge command threw the above error.

So one of the other upstream commands in loadocdelections must also be a factor. I'm looking at you loadocdcandidaciesfrom501s.

The merge we're attempting when this error is thrown is BRIAN DAHLE in the ASSEMBLY 01 race in the 2016 GENERAL.
However, this merge shouldn't even be happening. There are only two candidacy records for this contest, and only one of them is named BRIAN DAHLE:
select
    c.candidate_name, p.name, c.extras, c.registration_status, c.person_id, c.party_id, *
from opencivicdata_candidacy c
join opencivicdata_candidatecontest cc
on cc.id = c.contest_id
join opencivicdata_election e
on e.id = cc.election_id
join opencivicdata_person p
on p.id = c.person_id
where e.name = '2016 GENERAL'
and cc.name = 'ASSEMBLY 01';

With a little extra logging, it looks like the merge is being attempted because of grouping by person other names.

So it seems like there are actually two issues here:

The query generated in the .group_by_other_name() method on mergeocdpersonsbycontestandname should counting the number of distinct person_ids that share the same other_name, but isn't.
Somewhere we are inserting duplicate opencivicdata_person records with the same person_id and name values.

As for the first issue, this is the query currently generated by the Django queryset:
SELECT
    "opencivicdata_personname"."name",
    COUNT("opencivicdata_candidacy"."id") AS "row_count"
FROM "opencivicdata_candidacy"
INNER JOIN "opencivicdata_person"
ON ("opencivicdata_candidacy"."person_id" = "opencivicdata_person"."id")
LEFT OUTER JOIN "opencivicdata_personname"
ON ("opencivicdata_person"."id" = "opencivicdata_personname"."person_id")
WHERE "opencivicdata_candidacy"."contest_id" = ocd-contest/fb5e994b-ed61-44dd-b554-59847b4e2e94
GROUP BY "opencivicdata_personname"."name"
HAVING COUNT("opencivicdata_candidacy"."id") > 1;

But I think this is the query we want:
SELECT
    "opencivicdata_personname"."name",
    COUNT(DISTINCT "opencivicdata_candidacy"."person_id") AS "row_count"
FROM "opencivicdata_candidacy"
INNER JOIN "opencivicdata_person"
ON ("opencivicdata_candidacy"."person_id" = "opencivicdata_person"."id")
LEFT OUTER JOIN "opencivicdata_personname"
ON ("opencivicdata_person"."id" = "opencivicdata_personname"."person_id")
WHERE "opencivicdata_candidacy"."contest_id" = 'ocd-contest/fb5e994b-ed61-44dd-b554-59847b4e2e94'
GROUP BY "opencivicdata_personname"."name"
HAVING COUNT(DISTINCT "opencivicdata_candidacy"."person_id") > 1;

Think I solved the distinct count issue.
However, when I re-ran loadocdelections I got the same error because now there are two candidates in a contest with the same person_id:
select
    c.candidate_name, p.name, c.extras, c.registration_status, c.person_id, c.party_id, *
from opencivicdata_candidacy c
join opencivicdata_candidatecontest cc
on cc.id = c.contest_id
join opencivicdata_election e
on e.id = cc.election_id
join opencivicdata_person p
on p.id = c.person_id
where e.name = '2014 GENERAL'
and cc.name = 'ASSEMBLY 06';

It's BRIAN CAPLES in the Assembly 06 in the 2014 General.

Caples is in our corrections file for this race. Wonder if that's a factor...

Re: the duplicate other name records...
This doesn't happen on the initial load of data. Actually, we only end up with 9 opencivicdata_personname records after the first run of loadocdelections.

First run of loadocdelections:

no errors

+--------------------------------+-------------+
| table                          | row_count   |
|--------------------------------+-------------|
| candidacy                      | 5890        |
| candidacysource                | 5890        |
| personname                     | 9           |
+--------------------------------+-------------+

Second run, no errors:

no errors
Loading additional candidacies from Form 501 filings

Processing Form 501: 728403

+--------------------------------+-------------+
| table                          | row_count   |
|--------------------------------+-------------|
| candidacy                      | 5890        |
| candidacysource                | 5890        |
| personname                     | 3545        |
+--------------------------------+-------------+

Third run:

Loading additional candidacies from Form 501 filings

Processing Form 501: 728403

Loading Candidate Contests

Created Candidacy: BRIAN CAPLES in Assembly 06
Created Candidacy: BRIAN CAPLES in Assembly 06

Merging 2 persons in ASSEMBLY 06 (in 2014 GENERAL)

BRIAN CAPLES (ocd-person/adde3938-15bc-4766-b5f7-f1d144f005bd)
BRIAN CAPLES (ocd-person/adde3938-15bc-4766-b5f7-f1d144f005bd)

Then an error

+--------------------------------+-------------+
| table                          | row_count   |
|--------------------------------+-------------|
| candidacy                      | 5892        |
| candidacysource                | 5892        |
| personname                     | 7081        |
+--------------------------------+-------------+

Suspects:

.add_other_name() on OCDPersonProxy, which is called:

In .get_or_create_from_calaccess() on OCDPersonManager
In two different places on .get_or_create_from_calaccess() on OCDCandidacyManager

.update_name() on OCDPersonProxy, which is called in .get_or_create_from_calaccess() on OCDCandidacyManager.

Need to keep an eye on deltas to opencivicdata_candidatecontest as well.

I believe this has been settled.


ci: use CircleCI 2.1 config

Signed-off-by: Lizan Zhou<EMAIL_ADDRESS>Description:
Use CircleCI 2.1 executor config to simplify CI config.
Risk Level: Low
Testing: CI
Docs Changes: N/A
Release Notes: N/A

You need more than just config change. You ahve to change the circleci settings in admin portal to use the experimental settings. And when we do that, GH or circleci will likely mess up the webhooks and create build-2, asan-2, etc.. :).. So, we have to go back to GH and mark the new ones are required and remove the old ones..


Map: "ghost marker effect" - marker popup flashes when hovering

This is difficult to reproduce, so I took a screencast of the issue, along with some minimal console logging. It's clear that the popup is opening, and then immediately closing, over and over.
Screencast from 2023-10-25 13-26-09.webm
ETA I called the method openPopup() on the leaflet marker object, and this is the result:

I suspect the large size of the popup content, along with our repositioning logic, is contributing to this issue.

Setting overflow: hidden to .leaflet-popup-pane stops the flashing behavior. So, I believe that addressing the size issue will fix this.

I spent time looking at this, but did not yet figure out why the plot is so huge.
Some details...

The plot for the problematic marker popup has fixed dimensions (something like 700px x 500px)
The plot for "normal" marker popups have dynamic dimensions (100%).
It's not clear where the fixed dimensions are coming from. I suspect plotly is using a default for some reason.

Given the inability to reliably reproduce this issue, it's mostly guess work. I think the next step is to add lots of logging, hoping that a pattern emerges.

I've been trying and trying to reproduce this on prod, but I haven't been able to. Maybe it only happens in dev?

Unassigned and moved to ready to work on, nice to have b68

@bobular have you been able to reproduce recently?

Yes, I've seen it plenty @dmfalke :cry:

We should probably look at all the tech debt and performance tickets and see which of those might affect this, before tackling it head on.  #862 looks like it should go first.

#862 is now closed by this PR: https://github.com/VEuPathDB/web-monorepo/pull/1112
Keep an eye out to see if the ghost popup is still an issue moving forward

Still an issue with React 18 (testing on qa.vectorbase.org) :cry:
Also I noticed that if you reload the page/map with a ghosty marker, it isn't reproducible.


Ability to add passes after default oir optimizations

Description
Adds a simple hook to run a user-defined optimization pass after the default passes are finished.

bors try

Please, merge if you approve my changes.


False alarm with dynamic_cast and reference type

I got the following null pointer dereference issue:
/Users/joshua/Documents/Infer/solidity/libsolidity/analysis/TypeChecker.cpp:372: error: NULL_DEREFERENCE
  pointer `lhs` last assigned on line 369 could be null and is dereferenced at line 372, column 20
  370.   	TupleType const& rhs = dynamic_cast<TupleType const&>(*type(_assignment.rightHandSide()));
  371.
  372. > 	bool fillRight = !lhs.components().empty() && (!lhs.components().back() || lhs.components().front());
  373.   	size_t storageToStorageCopies = 0;
  374.   	size_t toStorageCopies = 0;

And I believe this is a false alarm. What happens here is that a dynamic_cast is used with a reference type. This means that if the cast fails, an exception will be raised and so no null dereference actually happens. (Also it's a bit confusing lhs is consider as a pointer in the error message.)
I tried making a smaller test case, but did not succeed... So it seems that infer deals with dynamic_cast correctly, except in the above code. If there is anything I should try, just let me know.

The relevant code can be found here: Solidity TypeChecker.cpp:372 . Here is  a copy (TypePointer is a shared_ptr):
TypePointer const& TypeChecker::type(Expression const& _expression) const
{
	solAssert(!!_expression.annotation().type, "Type requested but not present.");
	return _expression.annotation().type;
}
[...]
void TypeChecker::checkDoubleStorageAssignment(Assignment const& _assignment)
{
	TupleType const& lhs = dynamic_cast<TupleType const&>(*type(_assignment.leftHandSide()));
	TupleType const& rhs = dynamic_cast<TupleType const&>(*type(_assignment.rightHandSide()));

	bool fillRight = !lhs.components().empty() && (!lhs.components().back() || lhs.components().front());

infer version 0.12.0

I couldn't reproduce your issue exactly, but I did spot another problem with shared pointers and dynamic casts to reference types. There is no guarantee it is the same as your issue.
Could you try modifying following code
to friend class infer_traits::TranslateAsType<T&>; in your infer release?
Then simply rerun infer analysis. You don't have to recompile infer with this change.

After some more testing of this change, it looks like it's breaking infer in many other places. I'll try to come up with proper fix and get back to you.


Dashboard unreachable when passing kubernetes CRD provider ingressClass

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?
Pass ingressClass into kubernetesCRD provider block
providers:
  kubernetesCRD:
    enabled: true
    ingressClass: traefik

This results in kubernetescrd.ingressClass arg being added into the deployment:
"--providers.kubernetescrd.ingressClass=traefik"
To reproduce:
helm repo add traefik https://helm.traefik.io/traefik
helm repo update traefik
helm install traefik/traefik --version 26.0.0 --set providers.kubernetesCRD.ingressClass=traefik --generate-name

navigate to load balancer endpoint /dashboard/ and get a 404

Removing the providers.kubernetesCRD.ingressClass=traefik works fine.
What did you see instead?
Dashboard endpoint on the load balancer responds with 404 when field is added. Dashboard is reachable without the ingressClass. The ingressRoute is not the issue here since I am bypassing it and talking directly to the service.
Setting non-default values for ingressClass also fails.
What version of Traefik are you using?
docker.io/traefik:v2.10.6
What is your environment & configuration?
        args:
          - "--global.checknewversion"
          - "--global.sendanonymoususage"
          - "--entrypoints.metrics.address=:9100/tcp"
          - "--entrypoints.traefik.address=:9000/tcp"
          - "--entrypoints.web.address=:8000/tcp"
          - "--entrypoints.websecure.address=:8443/tcp"
          - "--api.dashboard=true"
          - "--ping=true"
          - "--metrics.prometheus=true"
          - "--metrics.prometheus.entrypoint=metrics"
          - "--providers.kubernetescrd"
          - "--providers.kubernetescrd.ingressClass=traefik"
          - "--providers.kubernetesingress"
          - "--providers.kubernetesingress.ingressClass=traefik"
          - "--entrypoints.websecure.http.tls=true"
          - "--accesslog=true"
          - "--accesslog.fields.defaultmode=keep"
          - "--accesslog.fields.headers.defaultmode=drop"

Running on k8s 1.27, baremetal. Installed with helm chart traefik-26.0.0
If applicable, please paste the log output in DEBUG level
No response

Hello @keatsfonam,
That's an expected behavior of ingressClass parameter in Traefik Kubernetes CRD provider.
In the doc, it says:

If the parameter is set, only resources containing an annotation with the same value are processed. Otherwise, resources missing the annotation, having an empty value, or the value traefik are processed.

That means that dashboard ingressroute should have a kubernetes.io/ingress.class annotation.
Does that answer your question ?

Thank you, I missed that. I thought having it as the default ingressClass would be sufficient.


[Feature] Traffic Alerts

Show a traffic alerts button (if there are any) on the main page up in the header.

Mostly done! One last thing to do is check and make sure we do proper URL decoding, so we handle äs and ös correctly.
That's low-prio enough that we can probably push it to 1.1.

Something for 1.2: Refactor things into an AlertsService that tracks alerts seen, and is a central repository for received alerts so multiple pages can navigate to the alerts page without needing outside context.


HIVE-23633: Metastore some JDO query objects do not close …

…properly

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Tests passed. Hey @belugabehr @kgyrtkirk could you please take a look? :)

Hi @kgyrtkirk could you please take a look if have secs?

Hi @vihangk1, could you please take a look if have secs?
Thanks!

Hi @pvary, @nrg4878,  could you please take a look if have secs?
Thanks!
Zhihua Deng

Thanks for catching this!
We should close all the queries, even if there is an exception.
Since Java 8 closing queries in try-with-resources would be the best if possible, falling back to finally when not possible is the second best.

Thanks for catching this!
We should close all the queries, even if there is an exception.
Since Java 8 closing queries in try-with-resources would be the best if possible, falling back to finally when not possible is the second best.

Thank you for the review!
Introduces a new QueryWrapper to avoid superfluous exception handing when using try-with-resources with the class Query

Hi @pvary, any comments about the latest changes?  😄
Thanks,
Zhihua Deng

Hi @pvary, cloud you help merge this? thank you! :)

Hi @pvary, cloud you help merge this? thank you! :)

Ahh... Sorry for forgetting about this review. Could you please ping @belugabehr to check if he is OK with the current solution?
Also we will need to rebase / rerun the tests. I see that theoretically it can be merge without a conflict, but I have had headache several times merging changes with outdated tests which caused problems for the next contributor.
Thanks for keeping this PR alive @dengzhhu653!

Hi @pvary, cloud you help merge this? thank you! :)

Ahh... Sorry for forgetting about this review. Could you please ping @belugabehr to check if he is OK with the current solution?
Also we will need to rebase / rerun the tests. I see that theoretically it can be merged without a conflict, but I have had headache several times before with merging changes with outdated tests which caused problems for the next contributor.
Thanks for keeping this PR alive @dengzhhu653!

Thank you very much for the feedback and sorry for the late reply, I will rebase the commits. Hey @belugabehr, cloud you please take another look if have secs?
The issue can be seen in long live shared Metastore client(spark, client pool), the unreleased queries would accumulate to seeing the OOM. The former patch we applied to Hive version 1.2 solved it,  this patch introduces try-with-resource on the query and a sanity check on the master.

I'm a little confused here.  What version of JDO is Hive using?
It looks to me like Query should already be Autocloesable
https://github.com/datanucleus/javax.jdo/blob/fa061bf68e347b8fafca369ab589b7625d8579f3/src/main/java/javax/jdo/Query.java#L68
Thanks.

I'm a little confused here. What version of JDO is Hive using?
It looks to me like Query should already be Autocloseable
https://github.com/datanucleus/javax.jdo/blob/fa061bf68e347b8fafca369ab589b7625d8579f3/src/main/java/javax/jdo/Query.java#L68
Thanks.

Hehe. I have run the exact same rounds with @dengzhhu653. Autocloseableclose throws an Exception. We do not want to handle this individually, so we need the wrapper 😄