feat: added a way to wrap existing models with additional middleware

The idea is to be able to do things like
const smoothGemini15Flash = defineWrappedModel({
  name: 'smoothGemini15Flash',
  model: gemini15Flash,
  use: [
    retry({ maxRetries: 2 }),
    smoothStreaming({ cadence: 25, randomize: true })
  ],
});

await generate({
  prompt: prompt,
  model: smoothGemini15Flash,
})

What's the reasoning behind this instead of your first PR? I can see instances where I'd want to use each - middleware more oriented at specifics of the prompt would make sense to pass with generate, but middleware that I want to use to set "baseline behavior" for all prompts makes more sense with this approach.
If the question is around observability/tracing, I think we have some work to do there - I think generate should be an action instead of a wrapper around the model action. Tool loop etc. are too complex to not be brought into the observability story and I think we need to refactor.

What's the reasoning behind this instead of your first PR? I can see instances where I'd want to use each - middleware more oriented at specifics of the prompt would make sense to pass with generate, but middleware that I want to use to set "baseline behavior" for all prompts makes more sense with this approach.
If the question is around observability/tracing, I think we have some work to do there - I think generate should be an action instead of a wrapper around the model action. Tool loop etc. are too complex to not be brought into the observability story and I think we need to refactor.

The problem is with the playground -- middleware passed into the generate function directly is not accessible from the playground. This breaks several CUJs -- from simply being able to see the effect of the middleware in the Dev UI when playing with the model, to replayability of model call spans (not being able to replay the exact model call) when doing "Open in model playground" from a trace.
One way to work around it would be treat middleware similar to how we do tools -- we can register middleware in the registry (defineMiddleware) and pass in middleware refs to the generate call, which can be recorded in the trace and model playground can pass those in by reference... but this is a big full-stack undertaking... but perhaps worth it and we should add it to our backlog.

The problem is with the playground -- middleware passed into the generate function directly is not accessible from the playground. This breaks several CUJs -- from simply being able to see the effect of the middleware in the Dev UI when playing with the model, to replayability of model call spans (not being able to replay the exact model call) when doing "Open in model playground" from a trace.
One way to work around it would be to treat middleware similar to how we do tools -- we can register middleware in the registry (defineMiddleware) and pass in middleware refs to the generate call, which can be recorded in the trace and model playground can pass those in by reference... but this is a big full-stack undertaking... but perhaps worth it and we should add it to our backlog.

I think there's probably an "all of the above" here but I think it would be perfectly reasonable to ship direct-use middleware without playground support (you can still test it out by wrapping in a flow) and it would unlock the most flexibility for users. We could expand that to named/defined middleware as an "also" not an "instead of" which would potentially open up Dotprompt support:
middleware:
  - name: SomeMiddleware
    args: {a: 123}

The problem is with the playground -- middleware passed into the generate function directly is not accessible from the playground. This breaks several CUJs -- from simply being able to see the effect of the middleware in the Dev UI when playing with the model, to replayability of model call spans (not being able to replay the exact model call) when doing "Open in model playground" from a trace.
One way to work around it would be to treat middleware similar to how we do tools -- we can register middleware in the registry (defineMiddleware) and pass in middleware refs to the generate call, which can be recorded in the trace and model playground can pass those in by reference... but this is a big full-stack undertaking... but perhaps worth it and we should add it to our backlog.

I think there's probably an "all of the above" here but I think it would be perfectly reasonable to ship direct-use middleware without playground support (you can still test it out by wrapping in a flow) and it would unlock the most flexibility for users. We could expand that to named/defined middleware as an "also" not an "instead of" which would potentially open up Dotprompt support:
middleware:
  - name: SomeMiddleware
    args: {a: 123}

I very very strongly oppose the idea of direct use of middleware in the generate function. It undermines and breaks the core idea of trace + playground combo. It does it in very subtle way that will leave developers confused. I mean it won't throw errors or anything obvious, it will return different results (one way will apply middleware the other won't).

I'm confused...if I supply an output schema that also returns different results than if I don't. What's the scenario where this causes confusion? If I call generate in a code context and pass it middleware, that middleware should show up in the trace (I think that generate itself should be an action instead of a weird pseudo-wrapper around model actions FWIW).
If I'm in a playground and can't supply middleware, it's obviously not going to have the effects of that middleware applied. If I define a flow that includes a generate call that adds middleware, then I can call that in the playground and get the middleware applied.
I think "everything you can do with generate you can do in the model playground" is a reasonably good ideal to have, but I don't think the overall experience of Genkit breaks if there are some advanced things you can do in code that you can't do in the model playground.

In my dream scenario, a trace with middleware would have steps that look something like:
generate({
  model: gemini15Flash,
  prompt: "Do cool stuff.",
  use: [myMiddleware, mySecondMiddleware],
});

generate

myMiddleware

mySecondMiddleware

vertexai/gemini-1.5-flash

In my dream scenario, a trace with middleware would have steps that look something like:
generate({
  model: gemini15Flash,
  prompt: "Do cool stuff.",
  use: [myMiddleware, mySecondMiddleware],
});

generate

myMiddleware

mySecondMiddleware

vertexai/gemini-1.5-flash

You are definitely thinking outside the box here. It's not how we do it today. I mean, yeah, if we break up the trace for the generate function like that it solves the main problem I'm talking about, but the more middleware you put directly into the generate function the less useful Genkit tooling becomes.
Where's the line? How do you determine what's OK to call directly via generate and what's better exposed to the Dev UI? I mean, if you have some custom tool calling or output conformance middleware... obviously you want that to be available in the Dev UI. What about retry logic? Depends... but if it's some advanced self healing (feed the error back to the llm and ask to correct the previos output)... again, totally worth being available in the Dev UI. It's probably an exception rather than the rule when exposing something in the Dev UI as a model primitives is not useful.
If the user wants advanced features they should be building it on top of generate, not into it. Prefer composition of primitives.

What's the latest status of this conversation?

I think at the moment we're kind of at an impasse. I see middleware as being one of the most powerful yet simple-to-consume abstractions in software but I think my ❤  is not shared by most people. The in-use comparison is basically:
await generate({
  prompt: promptOrSomething,
  use: [myMiddleware({option1: true}), otherMiddleware()]
});

vs.
const before1 = await myNotMiddleware({option1: true}, promptOrSomething);
const before2 = await otherMiddleware(before1);
const unprocessedResult = await generate(before2);
// maybe you also did something after the request in one of the middlewares
const result = await myNotMiddlewareAfter({option1: true}, unprocessedResult);

Middleware is robustly configurable and allows for complex transformation in a simple package, but is harder to conceptualize for the people who write it (until they manage to completely grok the pattern at which point it becomes very straightforward, but this admittedly is not most devs).

the more middleware you put directly into the generate function the less useful Genkit tooling becomes

This is only true if we don't decide to make middleware a key part of Genkit including the tooling. I think adding middleware as a registry-backed primitive with full support in the DevUI is totally doable and would actually be really cool! Imagine if the model playground just let you add extra middleware like configurable retries or any number of things and then you can just export it to a dotprompt or code.

+1 to a registry-backed primitive. I haven not yet heard it discussed, but I think there are some nice possibilities for 3P middleware if we open it up. There are "generative" behaviors that not every model implements (such as system prompt) that we already express via middleware, and recently wrapping models w/ tool calling came up as something we should probably have (e.g. for ollama). Wouldn't it be cool if that were a middleware that could be retroactively applied by the developer to models that don't support it out of the box.

There are 2 ways to use middleware:

in a way that adds it to the action and can be played around from the Dev UI as a model (this PR).
directly in the generate function.

I think those two ways are kind of orthogonal. I think (1) should be at least one of the ways, I don't see why not.
I believe (2) has inherent issues, it's a slippery slope to making Dev UI useless over time. I'd like to avoid it. But we can continue the debate. In theory both those can be available.


[BUG] - when upgrading a cluster - the cluster manifest is corrupted

Describe the bug
I have an on-premise install of Service Fabric. It has been running without issue for over 18 months. However, it had not been patched, so was still running 7.0.x.x
To bring it to a supported version I needed to do a series of updates.
When doing a version update, the upgrade started OK, but the first node went into a boot/fail cycle for fabric.exe. On looking at the trace logs I found it could not make any network connections because it said it could not retrieve the certificate private key. Something it had no problem doing prior to the upgrade.
On looking at upgrade manifest file, in my case E:\ProgramData\SF\vm0\Fabric\work\FabricUpgrade\ClusterManifest.6.xml I found the X509 certificate name had gained a leading space e.g.
 <Section Name="ApplicationGateway/Http">
    ....
   <Parameter Name="GatewayX509CertificateFindValue" Value=" cluster1.mydomain.local" />

As a workaround, I found if edited this file to remove the space as the upgrade of the node was starting the upgrade completed without any issues - I know this is not good practice.
Area/Component:
Upgrade
To Reproduce
Steps to reproduce the behavior:

Perform an upgrade, the generated manifest file for the upgrade has a leading space

Expected behavior
The upgrade manifest e.g "E:\ProgramData\SF\vm0\Fabric\work\FabricUpgrade\ClusterManifest.6.xml" should match the currently active manifest on the cluster i.e have no leading spaces.
Observed  behavior:
On my cluster checking the active manifest via the browser UI or exporting it via PowerShell returns a manifest with no space in the certificate name.
However, the generated upgrade manifest does have leading spaces
Screenshots
None
Service Fabric Runtime Version:
I was on 7.0., and first saw this upgrading to 7.1. and then also 8.0.* and 8.2.*
I am now on 8.2.x
Environment:

3 Node on Premised Cluster
Windows 2016
Version now upgraded, using my workaround, from 7.0 to 8.2

Additional context
None

Assignees: /cc @microsoft/service-fabric-triage

Anyone got any thoughts on this?

Still seeing this problem when updating to 9.0.1553.950 > 9.1.1833.950.
Has anyone go thoughts why the upgrade manifest difference from the one I can export?

Still seeing this problem when updating to 9.1.1833.950 > 10.0.2226.9590 > 10.1.1951.9590
Has anyone go thoughts why the upgrade manifest difference from the one I can export?


Wait until imports resolve to stamp. Fixes #1500

Depends on https://github.com/webcomponents/webcomponentsjs/pull/310

LGTM


Development

@AlexandraArntsen merging from Dev to main should be no problem!

merging to get development and main on same level, since some changes were pushed to main.
it is already messy, so hopefully this makes it easier to get back to a clean development space.


Port for JupyterLab 3

Port the extension to JupyterLab 3
Fixes #10

Looks good, also tested locally with a lab3 environment, and seems fine.  Thanks @fcollonval !

@mlhenderson Do you need help to publish it? It would be nice to publish it on Pypi too as it is now possible with JupyterLab 3 to deploy extension as python package.

@fcollonval I don't have ownership for publishing to pypi and npm, but @shreddd does.


Make plugin APIs consistent

Currently netplugin/plugin APIs take an object ID as argument. This creates few problems:

objects need to be read twice, once by netplugin and again by the drivers.
When an object is deleted, there is no way for drivers to get the parameters of the object.

Instead, better way might be for netplugin to pass down the entire state to drivers as part of plugin API.
This issue tracks the API change required in netplugin and drivers.

This appears to be addressed. We can revisit if there is any api changes needed.


⚠ SceneTime has degraded performance

In cca06ea, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 13894 ms

Resolved: SceneTime performance has improved in 8126c3c.


Write documentation for using Portal.js

We need a detailed doc on how to use Portal.js. This doc should be a one-stop guide for setting up as well as using portal.js in building single or multiple dataset pages.
Acceptance

[x] I have a detailed documentation on portal.js that covers the following: s

[x] Introduces portal.js and its use Done see https://github.com/datopian/portal.js/pull/550
[x] Setting up portaljs locally Done see https://github.com/datopian/portal.js/pull/550
[x] Portal js components Done see https://github.com/datopian/portal.js/pull/550
[x] Contains some examples on using portaljs in:

[x] Building a single dataset page - https://github.com/datopian/portal.js/pull/627
[x] Building a CKAN powered catalog - https://github.com/datopian/portal.js/pull/626

[x] Deploying portaljs site to github pages Done see https://portaljs.org/learn/deploy-to-gh-pages

[x] Automated deploy with github actions
[ ] Local deploy with scripts

[ ] Developer setup

@risenW can you update in this issue on how we are doing ...

Hi @virgoaugustine could you check if your PR #619 fixes the task "Deploying portaljs site to github pages"?

@anuveyatsu yes it does. I will add a redirect url to https://portaljs.org/publish for that section.

OBSOLETE (and FIXED). Replaced by #530


Add Python package build validation

Fixes https://github.com/BYVoid/OpenCC/issues/821

The commit in this PR is also contained in https://github.com/BYVoid/OpenCC/pull/824


ci(jenkins): run full test matrix on a PR basis if comment

What does this pull request do?

Run nightly builds on a nighly basis.
Enable full test matrix if comment jenkins run the full tests

Related issues
closes #ISSUE

jenkins run the full tests please


std.socket.InternetHost.getHostByAddr unittest does not work with IPv6

dlang (@Vild) reported this on 2019-06-22T18:51:42Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=19997
CC List

bugzilla (@WalterBright)
shove

Description
The unittest[1] does not work when www.digitalmars.com resolved to a IPv6 address.

[1] https://github.com/dlang/phobos/blob/35e9f2fbbaab75815c01a7e6b7d207e98afb9d56/std/socket.d#L790

---

core.exception.AssertError@std/socket.d(790): unittest failure
----------------
??:? onAssertErrorMsg [0x7f7b50a58a23]
??:? onUnittestErrorMsg [0x7f7b50a58aa5]
??:? _d_unittest_msg [0x7f7b50a58d64]
??:? _d_unittest [0x7f7b50a58da5]
??:? _d_unittestp [0x7f7b50a58d1d]
??:? @safe void std.socket.__unittest_L773_C7() [0x7f7b4f81033c]
??:? void std.socket.__modtest() [0x7f7b4f81c636]
../druntime/src/test_runner.d:61 [0x56463967c9db]
../druntime/src/test_runner.d:32 [0x56463967c8e7]
../druntime/src/test_runner.d:13 [0x56463967c71f]
??:? runModuleUnitTests [0x7f7b50a59946]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x7f7b50a80c49]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x7f7b50a80bc4]
??:? _d_run_main [0x7f7b50a80b2a]
??:? [0x56463967cfa1]
??:? __libc_start_main [0x7f7b4b853ee2]
```

shove commented on 2019-07-05T12:19:00Z
https://github.com/dlang/phobos/blob/35e9f2fbbaab75815c01a7e6b7d207e98afb9d56/std/socket.d#L986

Also here, IPv6 can cause exceptions.
std/socket.d does not fully support IPv6, such as GetHostByAddr().

Perfecting std/socket.d to fully support IPv6 is certainly the best, but it's a bit of a workload.
So it may be a short-term solution to temporarily handle unittest to make it work properly. Otherwise, auto-tester of PR will be interrupted frequently.


feat: add bandwidth limit example

What type of PR is this?
feat: add bandwidth limit example
What this PR does / why we need it (English/Chinese):
This PR adds a rate limiting middleware to the Hertz server to limit the response rate to 100KB/s. This feature is useful to control the bandwidth usage and prevent abuse.
Which issue(s) this PR fixes:

Fixes #131

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@saixiaoxii Thanks, please raise another PR to fix the Copyright and typos. I will merge that one first.


Use of undeclared identifier RCTErrorUnspecified

Steps to reproduce

Build and Run in Xcode

Expected behaviour
The app builds for the ios simulator
Actual behaviour
Error logs 8 times:
Error in RCTCameraManger.m:
"Use of undeclared identifier 'RCTErrorUnspecified'"
Environment

node 6.2.2
React-Native 0.38.0
iOS 9.0,

react-native-camera
Version: 0.4.1

Hi Graham! Any luck? I am get same error!
/Umer

@umer990 @grahamtallen  Any luck with this, guys?

This is because you tried to use this library via cocoapods, but did not move react-native itself into Podfile, so react-native-camera pod installed default React pod as a dependency, which is of version 0.11, which is too old. Your options:

Do not use it as cocoapod, just react-native-link it into the project.
Find manual how to use react-native via pods (you have to do pod 'React' with a lot of subspecs and remove those libraries from your main project etc.). Add pod 'react-native-camera' as described here and DO NOT react-native link it, otherwise you'll have duplicate symbols in linker.

I had not used it as cocoapod, had directly installed it via npm. I think there was a version mismatch that was causing the problem.

Hello Team,
I am facing the same issue. Actually, I am getting an error on below line when trying to build:
reject(RCTErrorUnspecified, nil, RCTErrorWithMessage(error.description));
My details:  "react-native": "0.45.1",
"react-native-camera": "^0.10.0",
I have follow same instruction as mentioned on https://github.com/lwansbrough/react-native-camera.
Can you please provide any solution regarding this.


Fix GRPCLogClientAppender console warning.

[ ] If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
[x] Update the CHANGES log.

Console print warning
LOGBACK: No context given for org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender[null]

Move setOutputStream method from constructor to before start () method

@kezhenxu94 The lines is changed on 2021-02-21, thx for check again.


Device won’t have Internet access if device is connected to a VPN while jail breaking.

If a VPN connection is enabled while jail breaking, internet will not be accessible in the jailbroken state. If you may, please might you add a disable vpn feature just like the Wi-Fi disable, before the process starts.

Can't reproduce, works fine for me.

Can't reproduce, works fine for me.

I can open the vpn at first, but after using it for a while, I can’t open the vpn. The latest version of dopamine.

Fixed in 2.0.10+


Add Metrics Endpoint to Dapr for Prometheus

/area runtime

/area operator
/area placement
/area docs
/area test-and-release

Describe the feature
This is a feature request that span out of #945 that focuses on creating the Dapr metrics endpoint.
This will likely use the OpenCensus Prometheus exporter to add the metrics endpoint. The initial implementation will look to support the metrics exposed by ochttp.DefaultServerViews and future measurements can be added in follow up PRs.
metrics included in ochttp:

Requests count by method
Responses count by method
Size distribution of HTTP request bodies
Size distribution of HTTP response bodies
Server Latency

We now need docs for this.

Where would the docs live? directory /docs or docs repo?

Docs repo


If no prospectors set then don't update config

Without prospectors validate_cmd will not work so modifying to not create config resource unless prospectors is set. To resolve #83

If someone specifies prospectors in puppet (instead of hiera) this will always evaluate as though the config file doesn't need updating.

Code show as:
  if $prospectors_merge {
    $prospectors_final = hiera_hash('filebeat::prospectors', $prospectors)
  } else {
    $prospectors_final = $prospectors
  }

So if prospectors is set via puppet or hiera then prospectors_final shouldn't be empty.
Are you suggesting this gets done another way?

Basically I'm trying to find a way to include the filebeat class on any server with or without prospectors configured.
Without just means the package gets installed and uses it's default shipped configuration.
If the prospectors is set it would override.
Obviously as rspec tests are written it's looking for a filebeat.yml resource so they are failing

Prospectors can also be outside of the class declaration with their own defined type (filebeat::prospector {...)

I'm going to close this in favor of #83 for now since it looks like a different approach is needed.


footer-black-2 added

Good job @Hiresh007
Congrats 🎉, your PR got merged. To be eligible for the swags from ClueLess. Follow this steps.

Star this repository. ⭐
SignIn / SignUp in [ClueLess Website](https://www.clueless.tech/) .
Go to profile section from the top right hand corner.

Comment your profile URL under this comment tagging the person who merged your PR.

That’s it. Follow the leaderboard !
And don’t forget to share your achievement with your friends.


Comlink assets conventions

Implementation
We used .suma.js for maps because it will hightlight js code be default, but kept .suma so it is clear it is not just any js code. Before we settle on it, I'd like to hear others opinion. But personaly I like it.
Docs
I have skiped where to get comlinks and pointed to examples which are part of the repository.
In my opinion there is still confusion between OneSDK and SuperfaceClient. In many docs we refer to SuperfaceClient as OneSDK. Here I tried to use SuperfaceClient only.

First Saturday morning thoughts: I'd keep .js (for convenience I guess) and I would rename both SDK and the main class to OneClient 🤯

would love to hear @martyndavies take on this

So the constraint to keep same interface as in OneSDK 1.x and 2.x doesn't apply anymore? Because I'd like to at least remove the Result object of perform, in favor of throwing exceptions and returning result.

Here's my take. We should keep using .suma.js in the naming convention so there's always clarity about where the code came from and what it relates to. It allows us something specific to point at in documentation, removes the chances of accidental use elsewhere in an app through misnaming, and helps developer teams identify Superface generated code over their own, because they can always as "where does this .suma.js stuff come from".


columns argument (plus joins)

Description of feature
Getting some columns requires doing a join. For example, getting protein info for transcripts from  ensembldb:
transcripts(edb, filter = GeneNameFilter("ZBTB16"),
           columns = c("protein_id", "uniprot_id", "tx_biotype"))

We should be able to do this as well. This requires being able to figure out which table a column is in, then joining on that column.

How do we do discoverability for these? (#6)


avoid CLOP by removing unwrap

phase unwrapping is not necessary to obtain instantaneous frequency, and/but can lead to catastrophic loss of precision (CLOP), i.e. errors that grow with time; especially noticeable for long audio clips.
In tests, this proposed change led to better waveform reconstruction accuracy and faster execution.
Note that when reconstructing phase from dphase, cumsum should also be avoided as this too can lead to CLOP.
cf. https://gist.github.com/drscotthawley/3c812fde932c649cd3cd41ea8a29803c

@googlebot I signed it!

Cool, thanks for the contribution! This all seems fine, however it doesn't seem to be a limiting factor on audio quality for this model. Can you please set use_cumsum=True by default, so that the code still reflects the work of the paper by default?
Thanks!

Hi Jesse, I'm so honored that you'd check this out!   I'm happy to do as you ask, and will set use_unwrap=True and resubmit.
I think you wouldn't notice any difficulty for short audio clips and/or relatively high numerical precision, but for longer clips (longer than 1 second) and/or lower precision (e.g. FP16), you'll really notice the error accumulation affect the audio.   In my tests with 3-second-long audio and FP32, unwrapping yielded a maximum waveform reconstruction error of around 1e-3, whereas with this 'different' method it was only 4e-6, and the difference was audible.  Plus it ran 20-40% faster.
I only tested my method using numpy though (in the gist linked to above), not the full TF/magenta suite.   I'd love to hear if the altered version indeed works better for you, in terms of accuracy and/or execution time


Add lineinfo flag to PTX and SASS compilation

A line mapping between CUDA assembly code (PTX, SASS) and the original Python code is useful for many developer tools. The -lineinfo/-generate-line-info flag in CUDA generates this line mapping as annotations to the assembly (without changing optimization level). So it provides some amount of lightweight debugging information.
This change adds options at the CUDA compiler level for the relevant flags to the PTX generation (and JIT compilation to SASS) to generate this line mapping. It sets up a future change to enable the line mapping directly from the @cuda.jit decorator.
A test is added to the PTX generation which verifies the line mapping is present in the PTX after compilation from LLVM to PTX. No test of the new functionality is added to the PTX->SASS JIT compilation because there isn't already a simple test of this code path to base that on and adding one would be a fair amount of effort. However, we will be able to indirectly test the new functionality later when the cuda.jit decorator is added. I have verified locally with a prototype of the cuda.jit decorator change that the generated SASS looks good.

Note: it is already possible today to get this information with the debug=True decorator to @cuda.jit. The reason why a separate lineinfo option is useful is that lineinfo mode is intended to only generate the line mapping without any other debugging information generated (and the consequent loss of optimization that might result in).

I've not reviewed the code yet, but have experimented with this branch. Some observations:

It only seems to work with CUDA 11.2,  which is based on NVVM70. I suspect debug info generation for NVVM34 has various issues (there are some in the issue tracker) and I think it might have bitrotted a bit. For NVVM70 the same DIBuilder used by the CPU target can be used, which has probably had much more practical use and testing than the NvvmDIBuilder (which is only used for NVVM34). I don't think this is a problem - I think we should only support lineinfo for NVVM70-based toolkits, instead of trying to go back and fix the NvvmDIBuilder.
SASS seems to correlate back to SASS as expected (see attached image).
The lineinfo kwarg to the @cuda.jit decorator also seems to be working - I used it in my experiments, because I didn't read the PR description properly before I started testing :-)

@stuartarchibald I moved this back to 0.54 RC as I'm hoping we can get it over the line this week now it's updated.

@gmarkall I've updated the docstring for @cuda.jit and added a test which verifies the presence of the linemapping for this decorator.

Also worth noting: your previous comment indicated that I would need to make my changes from CachedCUFunction in CUDACodeLibrary but that appears not to have been necessary, because it is already implicitly passed through as part of the nvvm_options.

Also worth noting: your previous comment indicated that I would need to make my changes from CachedCUFunction in CUDACodeLibrary but that appears not to have been necessary, because it is already implicitly passed through as part of the nvvm_options.

I think you're right here - I hadn't realised it would already work for the reason you outline above.

(A couple of comments added, but I've flipped the status to "Waiting on reviewer") as i should still look at this more thoroughly.

Buildfarm ID: numba_smoketest_cuda_yaml_69.

Buildfarm ID: numba_smoketest_cuda_yaml_69.

Passed.


CMS-545: Add retry to fecth advisories on park operating dates page

Jira Ticket:
CMS-545
Description:

Found 429 errors happen only on TEST env when fetching the advisories data (e.g. https://bcparks.test.api.gov.bc.ca/api/public-advisories/items?filters[protectedAreas][orcs][$eq]=6197&pagination[limit]=100) but not on other envs or my local. Added retry with setTimeOut when it has an error to fix this issue. Any advice is more than welcome since I'm not really sure how to fix it 😅

I get errors intermittently from Strapi on the dev environment when I'm trying to build the site. It doesn't print out the error code but I bet they're also 429 "Too many requests"
Let's ask around and see if we can have the request limit raised a bit on these environments so we won't get the error anymore. Or at least not as often!


xds: add node ID to status messages generated by XdsClient

We don't currently have any tests that check the status messages.  That's something we should definitely fix, but it will be part of a broader effort related to reliability.  In the interim, I have manually verified that this works.

just an idea, could this test be leveraged: https://github.com/grpc/grpc/blob/93d47104daa789046b1d79db23faf52747450f58/test/cpp/end2end/xds/xds_end2end_test.cc#L2501 to also check for node ID?


how to add 'NodeExpandSecretRef' to CSIPersistentVolumeSource?

https://github.com/kubernetes/api/blob/7d47955f01bdcc2946a794248c1a65e3d419c0c9/core/v1/types.go#L1706

This support is added through
https://github.com/kubernetes/kubernetes/pull/105958


AST: Property requirements in @objc protocols should return true for requiresForeignGetterAndSetter.

We need to use ObjC dispatch to get to the witness of an ObjC protocol requirement. The wrong answer here was causing us to do the wrong thing when producing identifiers for key paths that refer to ObjC protocol requirements.
f7fc743

@swift-ci Please test

@swift-ci Please test source compatibility


iPhone X, XS, XR bug - Buttons overlap

A button placed in a transparent navigation bar is overlapped by the first button in the drop-down menu. This only happens with the newer iPhones (X, XS, XR) and when the navigation bar is set to be transparent.
Any thoughts on a fix?

If anyone runs into this issue, it was resolved by calculating the y offset based on screen height.


[Feature Request] Add Channel: Workplace by Facebook

Add channel: Workplace by Facebook
https://stackoverflow.com/questions/44058021/are-groups-in-workplace-by-facebook-supported-via-the-facebook-channel-on-micros

Thumbs up to vote

Closing this issue.  Messenger feature requests are tracked here: https://github.com/Microsoft/BotBuilder/issues/4360  (I've referenced this one there)


Add compose version support

Would you think about adding compose version support in the future?

That's a good request. Jetpack Compose has come onto my radar recently, and seems to be the default application type in the latest Android Studio.
At first sight it looks much nicer than the ugly XML based views that have been required in Android for a long time. It will also make the app's code a lot more equivalent to my iOS, web and desktop samples. That is good since the same patterns across technologies is something I'm trying to demonstrate.
So I will look to make such an update in the coming months, when I get some time. The way the code is structured, hopefully only view code will need to change.

I updated the UI to compose - it is quite a bit simpler now than the older XML views


chore(deps): update ci dependencies

This PR contains the following updates:

Package
Type
Update
Change

common-dev-assets

digest
f1b51cc -> cc6f9f5

github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper
require
patch
v1.21.0 -> v1.21.1

Release Notes

terraform-ibm-modules/ibmcloud-terratest-wrapper (github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper)
v1.21.1
Compare Source
Bug Fixes

deps: update gomod (#639) (97a2c5c)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

:tada: This PR is included in version 1.0.5 :tada:
The release is available on:

GitHub release
v1.0.5

Your semantic-release bot :package::rocket:


Fails to get Properties for connected database in ADS

Fails to get Properties with this error message:
Error calling SsmsMin with args '-a<EMAIL_ADDRESS>-S "xxx.xxx.xxx.xxx,31433" -U "sa" -u "Server[@Name='xxx.xxx.xxx.xxx,31433']"' - The system cannot find the path specified.

You need to run
gulp install-ssmsmin
prior to working on this in a dev environment.
(It'll be released as a package which will have the EXE included in it for release)


Add SBD logo and realms update

Hey Team,
This pull request is for adding a logo, banner image and token details for a new DAO project.

@Ahash1134
Hello and a very good day to you. I am just new to GitHub and I hope I can ask a question without sounding stupid. I have just started on my new path here and I was wondering if you are a 'Maintainer' that a workflow like this from which approval is required or have I missed something? I have done all I can remember and been taught so am uncertain if I am doing something wrong.
Kind Regards,
Alex


FIX: next drawable maybe nil crash

Thanks, fixed by https://github.com/c4games/engine-x/commit/208d07697f82ddb93f4cb76217b82c7b8ef81665


Make all the LazyList tests pass

Tests pass now, but there are still some unimplemented methods from the PySequenceMethods struct that are unimplemented.

Done as of 4d7f3dd7a55e6a3b46841c604681803dd1dc65b3!


Emit "bytes sent" metric from Datadog Metrics destination (and others).

Context
Title says it all, really.
Should encompass the actual number of bytes sent on the wire, to the utmost of our ability without going wild. Capturing the number of bytes sent in an HTTP request, for example would be good... but capturing all bytes sent through a client, including retries, would be best.

Closed via #379.


queue_type for max_outgoing_buffered_messages

Hi all!
I've got a question regarding "vmq_bridge.tcp.br0.max_outgoing_buffered_messages". Is it possible to change the queue type for this one aswell? At least currently it doesn't seem so.
Currently it will buffer the configured amount of messages and then discard all the new ones.
This results in old messages being potentially stored for a long time and more recent messages (that may even "update" a already buffered one) being discarded.
It might make sense to also have an option like queue_type for queued messages in bridges and set it to FIFO for example.

@cdro-idirect thanks, yep, that's currently a completely different queue implementation. The reason for that is that the outgoing buffer lives in the MQTT client of the bridge implementation.
A bridge is nothing more than an MQTT consumer bundled together with an MQTT publisher. So the bridge buffer is not living in VerneMQ, and has nothing to do with its rather sophisticated queue implementation.


Consider moving linting to xo

eslint has become difficult to maintain and is the bulk of our greenkeeper work.

Is the only motivation to doing this that greenkeeper is a pain to maintain? Is there a reason that we update dev dependencies (and not just project/product dependencies) with greenkeeper?

I can add 2 more motivations:

xo is catching a bit more suggestions for good code than raw-eslint (yup xo uses eslint under the covers)

less configuration for the project


OIDC Dynamic Registration: support registration access tokens

Let the dynamic registration of OIDC handle generation of registration access tokens which can then be used to look up client configuration, etc.

Going to close for the time being, until we run into a more solid use case.


feat: Add capacities to brillig vectors and use them in slice push

Description
Problem*
Brillig vectors didn't have capacities, so all operations were O(N) since they required copying the vector.
This PR adds capacities to vectors and starts using them in slice push to avoid reallocations and copies in push back.
Summary*
Additional Context
Unfortunately I can't make an e2e test showcasing a simple program where performance is good thanks to this due to reference counter weirdness:
unconstrained fn main() {
    let mut slice = &[];

    for i in 0..10000 {
        slice = slice.push_back(i);
    }

    assert(slice.len() == 10000);
}

After Array Set Optimizations:
brillig(inline) fn main f0 {
  b0():
    v1 = allocate
    store u32 0 at v1
    inc_rc []
    v4 = allocate
    store [] at v4
    jmp b1(u32 0)
  b1(v0: u32):
    v6 = lt v0, u32 2⁴×625
    jmpif v6 then: b3, else: b2
  b3():
    v8 = load v1
    v9 = load v4
    v11, v12 = call slice_push_back(v8, v9, v0)
    inc_rc v12
    store v11 at v1
    store v12 at v4
    v14 = add v0, u32 1
    jmp b1(v14)
  b2():
    v7 = load v1
    constrain v7 == u32 2⁴×625
    return
}

The inc_rc v12 makes it so the slice stored at v4 always has RC=2 so this optimization does not trigger.
It does trigger in other e2e tests though.
Documentation*
Check one:

[x] No documentation needed.
[ ] Documentation included in this PR.
[ ] [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

[x] I have tested the changes locally.
[x] I have formatted the changes with Prettier and/or cargo fmt on default settings.

It's normal for bytecode to be marginally bigger: the procedures need more bytecode to use capacities. However they are deduplicated, so the bytecode size increase is independent of program size.

After this PR I'll add more PRs to use capacities & RCs in the rest of slice ops


DOC: kmeans and kmeans2

It is not clear to me from the documentation when I should use kmeans and when kmeans2. The cluster.vq module docs do not clarify that either. There is also a StackOverflow question about this.
I think at least the names of the parameters and their description could be made consistent:

kmeans
kmeans2

obs
data

k_or_guess
k

iter
iter

thres
thres

-
missing

check_finite
check_finite

codebook
centroid

distortion
-

-
label

There is only the note

a different implementation of k-means clustering with more methods for generating initial centroids but without using a distortion change threshold as a stopping criterion.

in kmeans. Just looking at the documentation, it seems to me that it might be possible to join those two functions to one. If missing is used, then kmeans2 is used.

I'm +1 for merging their functionality into kmeans and deprecating kmeans2. There's also a lot of room for optimization.

There's also a lot of room for optimization.

Indeed. Here's a nice benchmark: http://hdbscan.readthedocs.io/en/latest/performance_and_scalability.html#comparison-of-high-performance-implementations. The scikit-learn implementation is a lot faster.

@rgommers You may have noticed the recent issues #8683 and #8727. Besides fixing these bugs, do you think scipy.cluster.kmeans is something that should be improved further (like by addressing this issue and perhaps finishing #4119), or should we continue to offer it for convenience and refer users to scikit-learn for performance? @perimosocordiae I see you've been active on all the kmeans issues. What do you think?

I'd say merging the recent PRs and closing this issue by merging the implementations make sense. gh-4119 could be merged if someone picks it up, but that's already in the "new features" domain. I'd say simple PRs that make things better should continue to be accepted, but I'd say for nonstandard functionality and optimal performance we should just refer users to scikit-learn.


darviz-git plus bluemix testing

Please Ignore
Submitted by<EMAIL_ADDRESS>

How do I delete or edit a node right click doesn't offer options

If you want to delete a node from workspace - you can simple select the node and press the delete button.
If you want to edit the parameters of a node - do a double left click to get the options menu.
Are you looking for any other edit operation on the node?


CODE DEADLINE - Tuesday 7th May 23:59

With the deadline in 168 Hours (7 days) from now, we need a deadline for the code so we can have time package up and do this youtube video too as well as confirm details for the report.
That said I'm thinking the below as a code deadline:
Tuesday 7th May 23:59
giving us a day and a half to package, and do the video as well as final checks its all working.
NOTE: Tests for reports should be done ASAP not squeezed in after that date etc.
This deadline is simply to package and video up (releasing 1.0.0)
Please please please try and get all your bits checked in the code and any last changes done THIS WEEK, trying to finish code so everyone can then focus on final report :)

Any change to deadline is welcome too, just a general idea of a 'code deadline'

Sounds good Jack2.


[AutoPR network/resource-manager] [Networkwatcher] add a new field "Format" with new type"FlowLogFormat" to FlowLogProperties

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/4372

(message created by the CI based on PR content)

PR was closed


[WIP] Added get screen dimensions

Description
Added getScreenDimensions() that allows to get some screen specifications.
On iOS we can get screen dimensions in pt, px and mm.
On Android we can get screen dimensions in dp, px, mm. => WIP
Compatibility

OS
Implemented

iOS
✅

Android
✅

Windows
❌

Checklist

[x] I have tested this on a device/simulator for each compatible OS
[ ] I added the documentation in README.md
[ ] I mentioned this change in CHANGELOG.md
[x] I updated the typings files (privateTypes.ts, types.ts)
[x] I added a sample use of the API (example/App.js)

will close shortly in absence of feedback

@mikehardy
Sorry for the lateness of my response I was off.
I understand your hesitation. But as react-native-device-info user I really see it as the place where I can find informations relative to my device specifications: model, macadress, etc.. 🧐
And I see screen dimensions as a device specification.
I asked to developers around me and they had the same feeling 😄

I empathize with the point of view but the safely useful portion of the screen (which is the useful answer) is quite dynamic. It is not an intrinsic part of the device, it changes based on usage and current circumstance. I maintain react-native-safe-area-context is the correct home, and is actively developed. If they won't accept the functionality then we can see about it here - if that's the case in the end come back here and link the PR they rejected and we'll handle that as it may happen

It's also worth mentioning that the Dimensions API in react-native is completely broken since a really long time and facebook didn't really care about that. See: https://github.com/react-native-community/discussions-and-proposals/issues/291


Application starts redis cluster object memory is very high

Simply start the service, not for redis data read and write, use the top command to check the progress of about 800 MB memory (redis. NewClusterClient), stand-alone version of redis object does not exist the phenomenon, use the stand-alone version of redis object, using the top command to check the process of month around 67 MB of memory (redis. NewClient), I feel very confused, hope to get help, thank you!

What version are you using?

Thank you very much, problem solved

Showing nodes accounting for 53.48MB, 100% of 53.48MB total
Showing top 10 nodes out of 57
flat  flat%   sum%        cum   cum%
45.80MB 85.63% 85.63%    45.80MB 85.63%  server/pkg/engine.NewSocketConn
4MB  7.48% 93.11%        4MB  7.48%  server/vendor/github.com/syndtr/goleveldb/leveldb/memdb.New
1.50MB  2.80% 95.92%     1.50MB  2.80%  server/vendor/github.com/go-redis/redis.newClusterState
1.18MB  2.20% 98.12%     1.68MB  3.14%  server/pkg/datacenter.(*UserClientConn).processBizData
0.50MB  0.94% 99.06%     0.50MB  0.94%  server/vendor/github.com/go-redis/redis.commandInfoSliceParser
0.50MB  0.94%   100%     0.50MB  0.94%  server/vendor/github.com/go-redis/redis/internal/pool.NewConn
0     0%   100%     4.51MB  8.42%  main.main
0     0%   100%     4.51MB  8.42%  runtime.main
0     0%   100%     4.51MB  8.42%  server/cmd.Execute
0     0%   100%     4.51MB  8.42%  server/cmd.glob..func3


Random orange-ish rectangles

Describe the bug
When I run freeze file.swift it produces an image which always contains at least one orange-red rectangle that appears in the first 3 lines of code.
Here's an example

If the file is just 3 lines of code it works fine.
To Reproduce
Steps to reproduce the behavior:

Create .swift file and put

typealias PartOne = @Sendable (String) -> Int
@available(macOS 13.0, *)
let partOne: PartOne = { x in
  let digitPattern = /\d+/ // -- 1

  return x.split(separator: "\n").reduce(0) { acc, curr in // -- 2
    let matches = curr.matches(of: digitPattern) // -- 3
    guard let first = Int(matches.first!.0) else { return acc } // -- 3

    return acc + first + (matches.count > 1 ? Int(matches.last!.0)! : 0) // -- 4
  }
}

inside
3. run freeze file.swift
4. Tada !
Expected behavior
There should be an output image freeze.png
Desktop (please complete the following information):

OS: macOS Sequoia 15.1.1

I was able to reproduce this as well on master. I also tested the svg output and it didn't have this issue (attached)

Will have to take a look at the png conversion under the hood. Thanks for reporting this and providing us with steps to repro!


Unable to scale the kubernetes cluster after upgrading the kubernetes version from 1.7.9 to 1.8.2

Is this a request for help?:
Yes
Is this an ISSUE or FEATURE REQUEST? (choose one):
ISSUE
What version of acs-engine?:
canary

Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes 1.8.2
What happened:
I have upgraded my kubernetes cluster from version 1.7.9 to 1.8.2 using the "acs-engine upgrade" command. Then I tried to scale my cluster using the command "acs-engine scale". Scaling the cluster is failing with the below error.
{
"error": {
"code": "PropertyChangeNotAllowed",
"target": "customData",
"message": "Changing property 'customData' is not allowed." }
{"code":"PropertyChangeNotAllowed","target":"osDisk.createOption","message":"Changing property 'osDisk.createOption' is not allowed."}
What you expected to happen:
Scaling of the cluster should have been successful.
How to reproduce it (as minimally and precisely as possible):

Create a ARM template for kubernetes cluster using acs-engine with custom Vnet specs. Use Kubernetes version 1.7.9

Deploy the ARM template using the command  "az group deployment create"

Update the route table settings as specified in the acs engine docs for custom vnets.

4.Upgrade the cluster to version 1.8.2 with the help of acs-engine.
acs-engine upgrade --subscription-id 51ac25de-afdg-9201-d923-8d8e8e8e8e8e
--resource-group mycluster  --location westus2 \
--deployment-dir _output/mycluster  --upgrade-version 1.8.2
--auth-method client_secret --client-id 790c8dfc-d8f5-4zx6-b2b0-cxew1cbsf87d --client-secret 8d2972c8-zz71-2xc3-8e1e-18357e92cd8d

Try scaling up or down the number of nodes in the cluster.

acs-engine scale --subscription-id 51ac25de-afdg-9201-d923-8d8e8e8e8e8e
--resource-group mycluster  --location westus2
--deployment-dir _output/mycluster --new-node-count 5
--node-pool agentpool1 --master-FQDN mycluster.westus2.cloudapp.azure.com --auth-method client_secret --client-id 790c8dfc-d8f5-4zx6-b2b0-cxew1cbsf87d --client-secret 8d2972c8-zz71-2xc3-8e1e-18357e92cd8d
Anything else we need to know:

+1 What is the resolution for this?


⚠ ClamAV has degraded performance

In 4d4b1be, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 193 ms

Resolved: ClamAV performance has improved in 04e860b after 5 minutes.


Change Browser Settings

Hi, Its any way to change browser screen resolution, and other browser params such user-agent?

have news？  another is how do you set up the proxy.  This also would be really helpful.

There isn't a way change change these settings from API, but you could either modify some config files or write some code to do it.
For browser resolution, check the folder returned by r.tagui_location() --> there should be a tagui folder (Windows) or .tagui folder (Linux, Mac) under that location. Then go to src/tagui_config.txt file to modify the browser size.
For maximising Chrome and setting proxy, using visual automation mode and keyboard() to automate the manual actions required to maximise window or set proxy in Chrome. The proxy has to be set in Chrome this way. Alternatively, modify the file src/tagui.cmd (Windows) or src/tagui (Linux, Mac) so that the chrome command launches with the right proxy parameters.
For browser cookies, the is the src/chrome/tagui_user_profile folder which is actually your Chrome user and cookies. You can manually back it up and move it back before running r.init(), for Chrome to pick up the user saved settings and cookies. Alternatively, you could hack the tagui.cmd or tagui file to run Chrome with a specific user profile directory.

Tagging @JoseZamora97 @Kendsito @daimengxiaozhi


Error executing speedtest

Home Assistant release (hass --version):
0.63.1
Python release (python3 --version):
Python 3.6.3
Component/platform:
speedtest
Description of problem:
Error executing speedtest: Command '['/usr/bin/python3', '/usr/lib/python3.6/site-packages/speedtest.py', '--simple']' returned non-zero exit status 1.

Expected:
Problem-relevant configuration.yaml entries and steps to reproduce:

Upgrade to 0.63.1
Error

Traceback (if applicable):

Additional info:
hassio 1.0.1
Since I upgraded to 0.63.1, speedtest is no longer working. Possibly related to https://github.com/home-assistant/home-assistant/pull/12377 ?

Don't know what happened but I only did an extra reboot and now it seems to be working again.

#12377 is only available in dev and not 0.63.1.


bugs: b/28851938, b/28888701

@dumbunny @mattharden
The mysql API bug seems to trigger for very large data sizes,
likely greater than 1<<20. This is because we make go think
that those slices can't be bigger than that value.
The other fix is to prevent a divide by 0 error.

This change is

LGTM

Hmm. Of course. It's 64 that we should be afraid to use. What was I thinking.


Add a testing module

I would be awesome if there was a testing module, that would include neotest, and would integrate with the debugger.
I feel it's not the simplest thing to implement by hand so it would be great to have it built in!

It's in the works! (and its based on neotest).
The module is actually pretty much done, I just need to add unit tests for Nyoom's macros, standard library, etc, which its taking a tad bit longer


crds: Add support for deploying CRDs before other resources.

This handles an inherent race condition in kubernetes in which kubectl apply applies manifests too fast such that if you apply a new CRD and a resource that uses that same CRD in the same apply call, the application will fail with no matches for kind <foo> in version <foo version>. The traditional fix is to apply CRDs first, and then wait for them to be established before applying the rest of the resources.
This is accomplished by adding a new binary called sorter into the fold. sorter will sort the yamls based on things that should be applied first (ie, namespaces should always be applied first, etc) and also can optionally filter based on kind. If we specify waiting for CRDs, we will use apply CRDs first using the sorter, wait, then apply the rest of the manifests.
Of note, kustomize offers basic sorting, but it doesn't handle the majority of resource types and being beholden to kustomize's sorting means we cannot alter it. So we disable kustomize sorting in favor of our own.
Also of note, when deleting manifests, we must delete resources in the opposite order because if we disable a CRD first, it will delete all usages of the CRD causing delete to fail because it will try to delete a non-existing resource.

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

This is just my initial iteration with the basics. If the approach seems viable, I'll clean it up and more tests.

@apesternikov Have you had a chance to take a look at this?

@DolceTriade, we appreciate the contribution.  Tut the way this PR is implemented is going against initial design goals for the .apply verbs.

There are solutions that allow influence resource sorting using kustomie.
.apply verbs were never meant to become a deploy tool. The ruleset is called "gitops" to signify the GitOps workflow is a primary use case. The ruleset is agnostic to the deployment logic. Most implementations are using ArgoCD or some homegrown solution that is capable to accommodate the in-house implementation requirements.
The CRD provisioning issue is such a corner case that doesn't warrant additional complexity. CRDs and other cluster-scoped resources are usually maintained by the cluster administrators. That means those are at least separate targets.


Feedback on documentation

I had volunteered to be part of the PCWG tool beta testing group, headed by Paul Housley.
I have downloaded the tool 0.7.0-BETA.1 and I have two datasets that I intended to use for testing.
I feel that the documentation supplied with the tool is very much lacking. I have recently joined the PCWG (end of 2016) and I do not understand what the tool is doing and which settings are appropriate for the particular dataset you are considering. Perhaps if you have been using the tool for a long time and have experience of earlier versions that were simpler, it seems obvious, but for someone looking at it for the first time, it is not.
I have read through the "PCWG Open Source Tool Overview" document and also watched the youtube video. I very much feel that a step-by-step guide and worked example, with explanations of why particular settings have been chosen for the dataset, would useful.
I am sorry that I cannot be of much help in testing the tool for the beta deadline this week.

Hi @eljc2
Thanks for this feedback; it is much appreciated. We certainly acknowledge the documentation is lacking and it is an aim to improve it.
For context, the tool has changed a lot over the past year or two, both in terms of the analysis it performs and the user interface. As such, with limited time available improving documentation was not a priority (the tool would soon evolve making it obsolete). The tool is now much more stable in its design and so now is a great time to start thinking about the documentation.
GitHub itself provides a very nice Wiki feature (PCWG Tool Wiki exists but is hopelessly out of date and/or incomplete). I feel this could be a nice place to document the tool, perhaps with a link to this Wiki present in the user interface for easy access. We could include:

guide on how to use the tool

steps to setup a dataset, portfolio, custom analysis etc
guide to the data entry required in the various windows in the UI

definition of PCWG terminology (particularly some of the ambiguous variable names in the UI)
description of the analysis methodologies implemented

Would a guide in this form be useful? Anything else you would like to see included that I haven't mentioned?
Thanks,
Lee.

Hi Lee
Thanks for your quick response. Yes, a guide in that form would be very useful. Also, I would like to see the guide help the user to decide which settings are relevant or not important for the dataset they have and/or type of analysis they are doing. Also an indication of how these settings might be expected to impact the results. This will help the user make a decision on settings, or else risk skipping over things that might be important.
Cheers,
John


Update to nightly-2021-09-11

There are quite a few changes in rustc I had to address, most notably black_box is now a backend-driven intrinsic.  No more hacks for llvm_asm!
I haven't yet looked at the codegen tests: no spare time, sorry. Hopefully, this evening.

(There are not enough hours in the day)
I have good news, bad news, and bad news (it's midnight and I'm a little bit unimaginative at midnights; I'll catch up another day).
Good news: I've been able to verify that the clobber_api is indeed correctly translated to out("reg")_ operands, transparently to the backend (I compiled a simple separate file). Also, turns out that not every register's name as given by rustc is a valid GCC name for the clobber list. I'm sending a separate PR for it.
Bad news: running codegen tests in requires being able to save intermediate artifacts to a file (judging by this). I haven't find a way to save GIMPLE to a separate file, or anywhere but stderr. (I checked your fork as well). Related to #81.
Bad news: clobber_api("C") clobbers k[1-7] AVX-512 registers, which the docs of course do not mention. I'm starting to love open-source world, and it's very weird, kiss-kill kind of love. Unfortunately, GCC does not allow to clobber these registers unless the -mavx512f option is passed, and I see gccjit::context does not support testing for added options. Another path to libgccjit...

Bad news: clobber_api("C") clobbers k[1-7] AVX-512 registers

I think it should be changed to only do so when AVX-512 is actually enabled for the current function I think. It makes sense that GCC doesn't allow it when AVX-512 isn't enabled. I am slightly suprised that LLVM does allow it. cc @Amanieu.

which the docs of course do not mention.

The actual code for this is https://github.com/rust-lang/rust/blob/3ed6c1d23fd40f4367259a531465e809eb00ec27/compiler/rustc_target/src/asm/mod.rs#L802 which does indeed have k1-k7. Guess the docs need to be updated.

Yes, LLVM simply ignores any invalid clobbers. So for GCC you would just have to gate the clobbers based on what target features are enabled.

Note that this only applies to clobbers, LLVM still requires outputs (even dummy ones) to be valid registers for the current target.
This is the code that handles this in the LLVM codegen backend: https://github.com/rust-lang/rust/blob/master/compiler/rustc_codegen_llvm/src/asm.rs#L135

I see gccjit::context does not support testing for added options. Another patch to libgccjit...

I think this was wrong. We can just check features provided by the frontend as suggested by @Amanieu .

@Commeownist: Is it okay for you if I fix the remaining reviews in order to merge this PR? I'd like to merge it soon to update the PR in rustc to move things forward.

@antoyo Cool.

@antoyo I've resolved reviews (except I'd like to leave the TODO comment) and updated to nightly-2021-09-17. I think you can just merge it as is.
I'll leave codegen tests for another day.

There's an error in the CI which seems unrelated: it's about the bootstrap.

@antoyo Are you sure that rust-toolchain file is respected? These lines from the log make me somewhat concerned:
downloading https://static.rust-lang.org/dist/2021-09-08/rustfmt-nightly-x86_64-unknown-linux-gnu.tar.xz
...
extracting /home/runner/work/rustc_codegen_gcc/rustc_codegen_gcc/rust/build/cache/2021-09-08/rustfmt-nightly-x86_64-unknown-linux-gnu.tar.xz

I suspect it's relate to those wonderful git checkout <hash> commands all over test.sh.

Does this work locally? Perhaps the CI is having issue…

@antoyo Are you sure that rust-toolchain file is respected? These lines from the log make me somewhat concerned:
downloading https://static.rust-lang.org/dist/2021-09-08/rustfmt-nightly-x86_64-unknown-linux-gnu.tar.xz
...
extracting /home/runner/work/rustc_codegen_gcc/rustc_codegen_gcc/rust/build/cache/2021-09-08/rustfmt-nightly-x86_64-unknown-linux-gnu.tar.xz

Rustc uses a nightly rustfmt instead of the version associated with the bootstrap compiler. I don't quite remember why though.

Bootstrap failed due to a new warning about an unused field that doesn't exist on beta. You could add deny-warnings = false to the [rust] section of config.toml:
https://github.com/rust-lang/rustc_codegen_gcc/blob/8ec7976ced61c31dbcaeda3f52d7ecc197764f80/test.sh#L150

@antoyo Ready

Thanks!


Add "common corruption" transformations as a warmup attack

I think that the transformations from Benchmarking Neural Network Robustness to Common Corruptions and Surface Variations by Dan Hendrycks and Tom Dietterich would be a good addition to the warmup attacks.

Three reasons why I think that this would be a good addition:

Their corruptions clearly illustrate a set of non-lp-restricted attacks
These corruptions are strictly easier than an unrestricted adversary
They have a simple and well-designed codebase

Tasks

[x] Check their license (👍 Apache is good)
[ ] Convert their library into a pip module (either in place or copy it into this repository)
[ ] Add all transformations at severity 1 as a warmup attack on the bird-or-bicycle dataset (Perhaps 10 transformations per image)
[ ] Evaluate baseline defenses
[ ] Inspect confident misclassifications to ensure that they are unambiguous to a human

I think that this would be most relevant for the bird-or-bicycle dataset (because that's what the original authors designed it for), and need not be added to MNIST.

@hendrycks has volunteered to be the author of this after the ICLR crunch
https://github.com/hendrycks/robustness/issues/2#issuecomment-423273663
Thanks!

Added in #51


Certain initialDate breaks simulation

When I run a simulation on the 45 minutes time period with the following initial date, everything seems to work fine:
{
"initialDatetime": "2019-08-01T00:00:00.000Z"
}

However, the following date doesn't:
{
"initialDatetime": "2019-04-01T00:00:00.000Z"
}

The symptom is the simulation doesn't show on screen after more than 20 minutes.
Looking into the logs I see that several execution periods have the following in common:

Initial date is initialDate = Thu Aug 01 2019 02:00:00 GMT+0200 and candle 0 starts at 2019-8-29 02:00:00.
Attaching one log file:
Loop.00000001.0001.txt
... and also Share Definition (notice txt file extension):
Share - Definition -  (1).txt
I tried in 40 min time period and the same problem occurs.

With the latest version of the app and data, simulation on daily files are not working at all, even without a set initialDatetime.
Jason's log ends in the same odd way in every execution:

The problem is not occurring with the latest release.


useStorage problem

Hello! Sorry for my bad english. I've got one problem with useStorage function.
If i write following code:
const user = useStorage('name', 'Bob');
console.log(user.value);
it will be 'Bob' in my console and localStorage will be empty, because storage.getItem('name') will return null, not undefined. And key name with value Bob will not be setted in my localStorage initially.

My browser: Google Chrome 87.0.4280.88

Good catch up! Mind open a PR for it? Thanks

Good catch up! Mind open a PR for it? Thanks


Update DoD

Description
Changes proposed in this pull request:

Update DoD

Related issue(s)

/retest


Eye in Speech Bubble

Emoji9 Fix 1.0-4 tested on an iPhone 6 running iOS 8.4
Extensive testing shows that one faulty emoji in Emoji9 is the 👁🗨.
Behaviors

Inputting this emoji works fine in Spotlight (displayed as one emoji)
Inputting does not work in Notes.app (disjoint into two emojis)
Disjoints upon deletion (in Spotlight)
Needs to press backspace for three times to completely remove (one for eye, one for the joiner, one for speech bubble)
All of the wrong behaviors above were not reproduced on a jailed iOS 9.2.

Is the problem fixed now?

Everything is fixed except that inputting and displaying does not work in apps (disjoint into two emojis).

@shicechi The only issue now would be when deleting those new emojis, emoji display has been fixed by EmojiAttributes.

@PoomSmart Confirmed.


Allow an option to not have command options auto resolve

Summary
Allow users to choose whether or not lightbulb auto resolves command options like hikari.User
Why is this needed?
Allow users more control, if they want to fetch the options themselves maybe
Ideal implementation
Probably adding an auto_resolve=False kwarg to command decorators, which defaults to True
Checklist

[X] I have searched the issue tracker and have made sure it's not a duplicate. If it is a follow up of another issue, I have specified it.

What format would the non-resolved options take? And would it only affect Hikari objects, or more generic ones like ints and bools too?

I'd probably have it return the ID of the object, it's the most useful. And it would only affect hikari objects like users and channels, to stop lightbulb fetching some information if you're gonna do it manually

These options are resolved by hikari, not lightbulb. What you are actually looking for is hikari.OptionType.MENTIONABLE.
@bot.command
@lightbulb.option("mentionable", "The mentionable to get", type=hikari.OptionType.MENTIONABLE)
@lightbulb.command("get", "Gets a user or channel id")
@lightbulb.implements(lightbulb.commands.SlashCommand)
async def echo(ctx: lightbulb.context.Context) -> None:
    m = ctx.options.mentionable

    print(type(m))
    print(m)

Oh I see. Well in that case this issue is redundant I suppose.

These options are resolved by hikari, not lightbulb. What you are actually looking for is hikari.OptionType.MENTIONABLE.
@bot.command
@lightbulb.option("mentionable", "The mentionable to get", type=hikari.OptionType.MENTIONABLE)
@lightbulb.command("get", "Gets a user or channel id")
@lightbulb.implements(lightbulb.commands.SlashCommand)
async def echo(ctx: lightbulb.context.Context) -> None:
    m = ctx.options.mentionable

    print(type(m))
    print(m)

Note that you can pass hikari.Snowflake in as the type instead of the OptionType directly

Forgot this issue was still open, I'll close it


x/build/cmd/release: menu install from right-click fails on Windows

What version of Go are you using (go version)?

go version go1.16.4 windows/amd64

Microsoft Windows [Version 10.0.19042.985]

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=\go-build
set GOENV=\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=%GOPATH%\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=%UserProfile%\Documents\
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=%ProgramFiles%\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=%ProgramFiles%\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16.4
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=\Temp\go-build3116843351=/tmp/go-build -gno-record-gcc-switches

What did you do?
Download latest windows msi package from https://golang.org/dl
Open Explorer and right-click to select "Install" menu (default in bold).

What did you expect to see?
Usual prompt to confirm installation.
What did you see instead?

Issue already occurs on go1.16.4
Workaround is to open CMD and run the msi. Then, the installation starts successfully.

I cannot reproduce this on windows, might be a antivirus thing or something local.

There is no report in the antivirus log but I cannot reproduce it anymore. Sorry for the noise.


Correctly handling empty DataFrames for selective operations

Adding a condition for selective apply operations that will simply
return an empty 2D numpy array for partitions if there are no
partitions.
This is added to both apply_func_to_select_indices and
apply_func_to_select_indices_along_full_axis

What do these changes do?

Related issue number
Resolves #368

[x] passes git diff upstream/master -u -- "*.py" | flake8 --diff
[x] passes black --check modin/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Modin-Performance-PRB/223/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Modin-PRB/284/
Test PASSed.


Why the change of the app name?

Why did you change the app name and icon?
Whatswrapp was much better.

Who's Down is now an app by Google https://whosdown.com/
Is this a potential issue?


Unable to disable linelens

Problem
Ionide no longer respects my config
  "FSharp.lineLens.enabled": "never",

an still shows the types as "comments" as shown in this screenshot

Steps to reproduce
Turn off linelens in VS Code settings.
They still show up.
Machine infos

Operating system: MacOS Cataline 10.15.4
VSCode: 1.49.0
Ionide-fsharp version: v4.17.0
Runtime: netcore
Dotnet version: 3.1.101
Runtime: .Net
Mono version:

Mono JIT compiler version <IP_ADDRESS> (2019-06/fe64a4765e6 Wed Sep 18 14:14:51 EDT 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug
	Interpreter:   yes
	LLVM:          yes(610)
	Suspend:       hybrid
	GC:            sgen (concurrent by default)

MSBuild version:

Microsoft (R) Build Engine version 16.3.0-ci for Mono
Copyright (C) Microsoft Corporation. All rights reserved.

I've been made aware this happens because "Enable pipeline hints" was introduced in a new update. This is super annoying, please change it so that it respects the existing  "line lens" setting.

LineLens and Pipeline Hints are two separate functionalities and users should be able to decide whether they want it on or off separately.


Incorrect handling of multi-disk offers

Fenzo misunderstands offers that contain numerous disk resources, as can occur when an agent is configured with multiple disks (as described here).    Fenzo consequently miscalculates the available disk resources.
The VMLeaseObject constructor iterates over the offered resources to identify the cpus, mem, and disk.  The last encountered disk resource wins, becoming the basis for the diskMB quantity.   The logic should only consider the 'root' disk resource, i.e. the disk without a source component.  This approach makes sense for frameworks that don't explicitly support non-root disks.
How to fully support multi-disk scheduling with Fenzo is considered a separate issue.

Noted.
The disk specification for the 'root' disk resource you mention is from a later Mesos version (post 0.24.x). Are you able to create a pull request for this change? Or, given an example that we could use to make the change? Or, can you create a unit test that would fail for the current version? Thank you.
Sorry about the delay in getting back to you, I was mostly out on summer travel and conferences.

@spodila have you seen much interest in adding disk support?   Or seen some applications of Fenzo that succeed in that?

@EronWright I've heard of one other user mentioning this would be useful for them. If you are thinking of creating a PR for this, that would be great.

@spodila I am interested in the functionality but don't have time to work on it at this time.

In addition for agents that will always have a small / partition (4GB), it means that only attached volumes will serve to host the 'sandbox'
so the issue here is that  you don't actually know where the disk comes from.
ideally the
public class TaskAssignmentResult

would give you a map for this successful result - in fact to all the original mesos.Proto.Offer.Resources  so you can see and track where they come from.
i.e: this class
public class VMAssignmentResult {
    private final String hostname;
    private final List<VirtualMachineLease> leasesUsed;
    private final Set<TaskAssignmentResult> tasksAssigned;

should have a way to go from the taskAssigned to  one of the leasesUsed (mesos offers) per sub resource, in particular for "disk" resources.

@spodila
here is an example:
{
  value: "2d024b1c-e037-44fd-a8f9-fa6ece3b181b-O1243"
}
framework_id {
  value: "------------xxxx-------------"
}
slave_id {
  value: "2e552da4-1c21-414c-ab2c-a29afc2b4027-S1"
}
hostname: "x.x.x.x"
resources {
  name: "cpus"
  type: SCALAR
  scalar {
    value: 6.0
  }
  role: "*"
  allocation_info {
    role: "*"
  }
}
resources {
  name: "mem"
  type: SCALAR
  scalar {
    value: 12949.0
  }
  role: "*"
  allocation_info {
    role: "*"
  }
}
resources {
  name: "disk"
  type: SCALAR
  scalar {
    value: 1728.0
  }
  role: "*"
  allocation_info {
    role: "*"
  }
}
resources {
  name: "disk"
  type: SCALAR
  scalar {
    value: 206312.0
  }
  role: "*"
  disk {
    source {
      type: MOUNT
      mount {
        root: "/partition1"
      }
    }
  }
  allocation_info {
    role: "*"
  }
}
resources {
  name: "disk"
  type: SCALAR
  scalar {
    value: 210338.0
  }
  role: "*"
  disk {
    source {
      type: MOUNT
      mount {
        root: "/partition2"
      }
    }
  }
  allocation_info {
    role: "*"
  }
}
resources {
  name: "ports"
  type: RANGES
  ranges {
    range {
      begin: 31003
      end: 32000
    }
  }
  role: "*"
  allocation_info {
    role: "*"
  }
}
executor_ids {
  value: "----------------------------------xxxx----------------"
}
url {
  scheme: "http"
  address {
    hostname: "x.x.x.x"
    ip: "x.x.x.x"
    port: 5051
  }
  path: "/slave(1)"
}
allocation_info {
  role: "*"
}

Thought the  LeasesUsed.getDiskMB() => 210338.0

Maybe there is a
struct NameDisk {
    double size;
    union type {
         mount  ....
         path
    };
}

So that you can get a getNamedDisk() and fill in the disk on the mesos protobuf

A possible workaround is to write an alternate implementation of VMLeaseObject as mentioned in #166.


Ignore files improvements

.eslintignore
As I understand the file is included for users that use the globally installed eslint. Hense I used eslint --ext .js,.vue to check the correctness of .eslintignore.
.eslintignore before
build/*.js
config/*.js

What is changed:

*.js suffixes removed because they are not necessary to ignore the whole build and config directories
If the / prefix is omitted than any config or build directories in the repository will be ignored (i.e. src/config/myConfig.js will not be linted). This PR adds the / prefix.
*.js config files from root directory are ignored by ESLint (currently they will fail linting process for airbnb style because of ; absence)
Unit testing generates *.js files that are contained deep in /test/unit/coverage/ folder. They will be ignored after PR merge.
Production build files in /dist/ will be ignored after PR merge.

.gitignore

added / to several paths (i.e. /dist/). So after this PR users will be able to add src/dist/normalDistribution.js to git repository.
I didn't add / prefix to node_modules/ because any nested node_modules folders are usually have related package.json and thus are not intended to be committed to source control.

Used resources

Official gitignore description.
Official Eslint docs

Any feedback is welcome.

Hey @exarus
Will look into this and probably merge for the next version, this looks like a great and long-needed cleanup!
Thanks!


Release 2.0.2

In this PR I'm creating the 2.0.2 release, upgrading the release steps and fixing setup.py for the new pypi requirements.

I'm sorry to bother you again @roccozanni, I already uploaded the file with 2.0.2 version prior to change the author and email. Now I can't rewrite that version as they're idempotent. We need to bump to another version 😞


Question on the code

Hi,
I'm trying to understand your code and reproduce the results. While reading through the code, I found that 'o_bestattack' at 'blackbox_attack.py' line 238 first initializes as a non-tanhed image but gets a tanhed image after attack success. Why is it not initialized as a tanhed image? Am I missing something?
Thanks.

Hi,
The o_bestattack is a variable for storing the best attack results. We initialize it with the original image  and this would not influence the attack. The class attribute USE_TANH will determine if tanh function will be applied on the image or not.
Bests
Chun-Chen


"You created a second Pretender instance while there was already one running"

I started getting this error today with<EMAIL_ADDRESS>and I'm fairly certain it has to do with Pretender 1.4.0 (that has a Notify on second Pretender fix)  that was released today.
beforeEach failed on visiting /myroute/foo: You created a second Pretender instance while there
was already one running. Running two Pretender servers at once will lead to unexpected
results!Please call .shutdown() on your instances when you no longer need them to respond.

This was in my acceptance test. I have failures in my integration tests as well, which look like:
Promise rejected before it renders: Assertion Failed: You cannot use the same root element
(#ember-testing) multiple times in an Ember.Application

So what is the appropriate way to shutdown the Mirage server? I currently have this in my acceptance tests:
afterEach() {
  Ember.run(application, 'destroy');
  server.shutdown();
}

Do I need something similar in my integration tests?

I found a workaround for both my acceptance and integration tests
In acceptance tests, my beforeEach() now looks like:
  beforeEach() {
    server.shutdown();
    application = startApp();
 },

I'm not sure why server.shutdown() in afterEach() doesn't properly shutdown the server.
And for my integration/unit tests, I've modified the code from Manually starting up Mirage to this:
// See: http://www.ember-cli-mirage.com/docs/v0.2.x/manually-starting-mirage/
import mirageInitializer from '../../initializers/ember-cli-mirage';

export default function startMirage(container) {
  if (this.server) {
    console.warn('Shutting down Mirage server before re-initializing');
    this.server.shutdown();
  }
  mirageInitializer.initialize(container);
}

All my tests now pass. I'm not sure if the above modifications are what I should be doing or not, however.

Same here.

Update:
It seems that updating module-for-acceptance.js to the newest version (from Ember CLI 2.8) and adding this snippet to integration tests which use Mirage:
    afterEach() {
      server.shutdown();
    },

does the job - everything is fine then.

Mirage monky-patches the server.shutdown for acceptance tests, but not for integration tests.  I suspect this will need to be done manually (as @netes has shown) and should be mentioned in the docs.

Is the https://github.com/samselikoff/ember-cli-mirage/pull/917 related to this issue?

Yes, it is an internal fix for the same thing.  Users will need to do this on their own for now.

Thanks @dustinfarris ! Sounds good!

I tried everything but still can't make it work even with one single acceptance test. Anyone is in the same case? I'm using a custom moduleForAcceptance this may be the reason why..

temporary workaround for us on #922

Pretender 1.4.1 is published and it will only give you a console.warn slap on the wrist.

Thanks @trek.  I think we should still try to dissuade users from overlapping servers going forward though by updating the documentation here.
For example, users relying on startMirage in their integration tests need to know why they are going to start seeing this warning.
I don't think there is a way to automagically handle this like we do for acceptance tests because moduleForComponent comes directly from ember-qunit, probably best to just advise users to run shutdown after using it.

Overlapping servers will also prevent some useful tools like https://percy.io/ from running in projects that use Mirage in tests.

I'm using mostly default generated tests with ember 2.10 and was having this issue. Resolved it by adding if(server !== undefined) { server.shutdown(); } to beforeEach and afterEach in each acceptance test file. As in,
module('Acceptance: Metro', {
  beforeEach: function() {
    if(server !== undefined) { server.shutdown(); }
    application = startApp();
    originalConfirm = window.confirm;
    window.confirm = function() {
      confirmCalledWith = [].slice.call(arguments);
      return true;
    };
  },
  afterEach: function() {
    Ember.run(application, 'destroy');
    window.confirm = originalConfirm;
    confirmCalledWith = null;
    if(server !== undefined) { server.shutdown(); }
  }
});

Hope this helps someone else having the same problem.

You saved my day! Thank you!


Possible Memory Leak in LFS push

Gitea version (or commit ref): 1.12.1
Git version:
Operating system:

Database (use [x]):

[x] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No

Log gist:

Description
I fetched all lfs files from one repo (not in gitea) with git lfs fetch --all  and pushed them to private gitea instance with git lfs push --all. First I allocated 500mb to gitea in container orchestrator, it was always enough for gitea that consumed only 128mb. I noticed that gitea was killed with OOM right after lfs push. Then I increased ram to 1gb, lfs push succeeded but memory consumption significantly increased to 780mb.
Screenshots

stats from orchestrator:

Golang holds 780MB, but it in fact use 116MB.

Yes, but in fact app memory consumption is still high. Can it be released back to OS ?

As @lunny says I don't think your graphs show a memory leak at all.
However the spike in memory consumption is concerning to me that the LFS stream is somehow being read entirely in to memory (temporarily) before being released.
That's weird though because we definitely try not to do that - so the question is where is that occurring.
Now I see that you're using 1.12.1 - it would be helpful is you could update to at least 1.12.5 as there was a problem with repo stats reading entire files in to memory in that version and then try again.

@zeripath ok, I will update gitea version and try again

I updated gitea to 1.12.5.
Before lfs push:

After lfs push files with total summary size 40mb:

The situation is now much better. However, Heap Memory Obtained is still significantly increasing (1.5x).

@zeripath I updated gitea to 1.12.5
Before lfs push:

After lfs push files with total summary size 40mb (like in original case):

The situation is much better now. However, Heap Memory Obtained is still increasing (1.5x)

In regards to relating heap memory that's something that you'd have to look at the golang tuning parameters. Garbage collected languages always have a delay between releasing memory and releasing heap. Go won't be using all that memory it's just there in case it needs it again.
Now the real question is the cause of that spike - because that worries me that we're loading a lot of stuff directly in to memory - which even if temporary is still bad.
The question is how to figure out what's doing that, where and how to stop it.
We do have a pprof option the problem is I genuinely don't know how to use it or where to look to learn about how to use it. But if you do - it's there for this reason.

I think this is likely related to the go-git memory leak problems and should now be fixed on the no-go-git pushes.
@v-byte-cpu would it be possible to recheck on master?

I think this is likely related to the go-git memory leak problems and should now be fixed on the no-go-git pushes.
@v-byte-cpu would it be possible to recheck on master?

yes, sure. Do you have pre-built docker images for master branch ?

yes, sure. Do you have pre-built docker images for master branch ?

Not sure if this is a separate issue or not but I'm seeing massive memory spikes and a consistent server crash on pushing a fairly large repo (2gb), seemingly at the end of the lfs upload.
Our gitea lfs is set to an external bucket (backblaze b2).
Our instance has 8gb memory and 8gb storage, but running df -h shows we use less than half the storage.
Upping the storage is no issue if that's the problem, but the crash is worrying considering I'd like to upload even bigger repos (even 20gb ones, but pretty much everything big goes to lfs)
This is the latest version (1.13.2) in a docker container on ubuntu.

What version?
Have you tried changing you password hashing algorithm from argon2 to a different algorithm?

I mentioned it at the end, 1.13.2.
I'll edit the comment to clarify.

I think #14673 and #14675 will fix the problem.

OK I think we can probably close this - as @lunny says the likely issue here is the memory use of argon2 on password hashing if you are using http(s) pushing.  I do expect that the no-go-git PR will also have helped.
Therefore I'm going to close this.
(Of note we will need to think carefully about argon2 and other hashing limits in future - perhaps with some maximal hashing pool or the like.)

Resolved by #14673 and #14675


ue4.25 link-filter.exe No child command line specified

Compile Unreal Engine 4.25.3
Exe: ...\Engine\Binaries\Win64\UnrealHeaderTool-BuildSettings.dll
EXEC : 1> error : No child command line specified.
Usage: link-filter.exe -linker= - - <child command line>
EXEC : Failed to build Exe. error : 1 (0x01)
Target: '...\Engine\Binaries\Win64\UnrealHeaderTool-BuildSettings.dll'

Compile Unreal Engine 4.25.3
Exe: ...\Engine\Binaries\Win64\UnrealHeaderTool-BuildSettings.dll
EXEC : 1> error : No child command line specified.
Usage: link-filter.exe -linker= - -
EXEC : Failed to build Exe. error : 1 (0x01)
Target: '...\Engine\Binaries\Win64\UnrealHeaderTool-BuildSettings.dll'

i have no idea of case in 4.25
maybe should modify the UBT script ---  UnrealBuildTool/Executors/FastBuild.cs , search the link.exe fix the error
or  do not use FASTBuild when execute link actions ( check the configuration , bFastBuildDisableRemoteLink.. )
the new version can work with UE4.24 , for exetracting code from UE4.26 , maybe can try the new lastest version agin  :)


Implement LazyLoadVersion

Implement lazy loading of a given version.
ref: https://github.com/cosmos/cosmos-sdk/issues/4326

Let me know if this looks correct @Liamsi or if there are any cases I need to be aware of. I've successfully tested this in Gaia.

@Liamsi that's a good point. And as you've brought up, I can't think of a reason why one would use LoadVersion() over LazyLoadVersion(). It's not immediately clear to me why you'd need to load all the roots -- I was hoping you'd have more context or a clue here.
If we are in agreement, how about we replace LoadVersion with LazyLoadVersion?

Sorry, I don't have any more context on this. Maybe @jaekwon (or @ethanfrey) have?

If we are in agreement, how about we replace LoadVersion with LazyLoadVersion?

As far as I understand it does not make sense to load all the roots. I'm OK with replacing LoadVersion with LazyLoadVersion.

Okay I am not 100% sure we should replace LoadVersion()
LoadVersion is not DOSable. LazyLoadVersion is. Ie. Once you load a tree with LoadVersion() the tree cannot be DOSed by creating a query pattern that requires loading lots of different tree versions to bring the node to a halt.
LoadVersion() can be used safely with a pruning node and queries against snapshots.
LazyLoadVersion() opts a node operator into new risks if the tendermint rpc is world accessible.

Valid concerns @zmanian. From doing another pass through of the IAVL implementation and it's relation/usage in the SDK's multistore (I've done this now a few times), I don't quite see where a DOS attack vector could occur? I could very well be wrong here. Here's what I can tell:

Height queries always call ndb.getRoot() regardless
Root node lookups ndb.getNode() can be cached
The only difference between LoadVersion and LazyLoadVersion is the former reads all the roots AND sets them in tree.versions[version].
I don't see how tree.versions would correlate to any DOSing or the prevention thereof. It's mainly only used when it comes to deleting.

Updated @zmanian. Also fixed the case when 0 is provided -- it loads the latest version by default. This was the previous behavior. I also need to update the semantics of Load.

Ok so actually taking a stab at replacing LoadVersion with LazyLoadVersion, I see why the need for the original logic exists:
The original LoadVersion() loads all the roots and as a result, when you load previous committed/saved versions and then try to overwrite a value and save, you'll get an error (as you should). I'm sure there are other cases similar to this.
That being the case, I'm going to leave LoadVersion as-is and keep LazyLoadVersion and update the godoc to state it should only be used in cases where only reads are necessary, not writes.


Fix cluster ID arrangement for chains

Addressed the issue related to different chains being clustered together incorrectly. This version will now offset the cluster IDs for each chain mapping, as discussed in #93.
Moreover, I tried to speed up the initialization of WeightedPDBSampler by removing some redundant type checks. It seems that this decorator slows down the parallelization of Polars, and removing all type checks will cut down the time from ~40s initially to around ~9s. In this version, I kept most of the ones added by @amorehead, but I removed the decorator from get_chain_count(), as it will always return a tuple of integers (or raise an error). Similarly, I removed it from calculate_weight() since we already employ the @typecheck for get_*_weight() functions. This change shaves off around 15-20s off of the class initialization.
Finally, in continuation to the previous Pandas → Polars change, I've made a small change to the filter_pdb_mmcifs.py code. It will now expect that the format of the release_date field of a mmcif_object header to always be %Y-%m-%d. This should avoid some surprise cases where the parser infers the format to be %Y-%d-%m.

@vandrw just so you know, you can turn off all typechecks by setting the environment flag TYPECHECK=False !

Ah, I see! I assumed that the type checking will stay on during training. That makes more sense now :)
Thanks a lot @amorehead for taking the time to improve my code! While going to bed last night, I realised that this change will compute different weights, and will lead to wrong outputs for the cluster_based_sample() method. For example, here is a comparison between interface cluster IDs used before and now:

pdb_id
interface_cluster_id
interface_cluster_id_name
...
interface_chain_cluster_id_1
interface_chain_cluster_id_2

str
i64
str
...
i64
i64

320d
4
nucleic_acid-ligand-SPM-4
...
10504
4

326d
4
nucleic_acid-ligand-SPM-4
...
10504
4

324d
4
ligand-SPM-nucleic_acid-4
...
4
10504

323d
4
nucleic_acid-ligand-SPM-4
...
10504
4

321d
4
ligand-SPM-nucleic_acid-4
...
4
10504

If we were to compute weights using the cluster_id introduced in your code, this would actually be done for two different clusters in this case: nucleic_acid-ligand-SPM-4 and ligand-SPM-nucleic_acid-4. Is the named version correct in this case? Or the numerical one?
If the latter, we should probably remove the following part in the code (Line 221 in weighted_pdb_sampler.py), to avoid sampling from incomplete clusters during cluster_based_sample() :
# Add additional information to the cluster IDs
chain_mapping = chain_mapping.with_columns(
    (pl.col("molecule_id") + "-" + pl.col("cluster_id").cast(pl.String)).alias("cluster_id")
)
interface_mapping = interface_mapping.with_columns(
    (
        pl.col("interface_molecule_id_1")
        + "-"
        + pl.col("interface_molecule_id_2")
        + "-"
        + pl.col("interface_cluster_id").cast(pl.String)
    ).alias("interface_cluster_id")
)

@vandrw, I have been assuming up to now that these interface cluster IDs should be unchanged by the ordering of the first and second chains. In practice, seeing a SPM ligand interact with a nucleic acid chain is the same thing as seeing a nucleic acid chain interact with an SPM ligand. Let me know if you agree with this assumption of mine.

@vandrw, after thinking through this more and re-reading the AF3 paper, I believe you are correct. We should not include the molecule_ids as part of the interface_cluster_ids and should rather keep the interface_cluster_ids as integers incremented by the maximum chain cluster ID. I've made a PR to address this issue.
Also, after looking back over the AF3 paper, I personally lean towards using the sample function as a default over the cluster_based_sample, mainly because that is the most literal interpretation I can draw from DM's description in Section 2.5.1.


Running behind a HTTP proxy

I did some testing of ConanMultiPackager locally today at work where there is a firewall.  I am using CONAN_DOCKER_IMAGE and it hangs at the pip install step.  I can get pip to work through the proxy using pip --proxy=xxx but not using environment variables.   Is there a way around this?  If not could you add another environment variable that is used as the --proxy argument to pip (or something more general)?

But only for pip? what about the conan downloads?

Good point - my particular project doesn't have any requirements so the pip problem was the only one I had seen (so far).

Could you configure that machine to connect using the proxy at OS level?

Is that possible using Linux?

Yes, definitely, you can configures proxies at the system level, every distro will have its way, here is the ubuntu one, for example: https://help.ubuntu.com/stable/ubuntu-help/net-proxy.html

Hi @sourcedelica !
Did you solve your problem?
You could configure Docker to use your custom proxy:
https://docs.docker.com/network/proxy/


filter_blacklist doesn't support obtaining custom blacklist from custom genome

Hi,
I want to draw attention to a bug that occurs when I try to use a custom blacklist file for my custom genome when calling grelu.data.preprocess.filter_blacklist. The function get_blacklist_file is called before filter_blacklist can check if I have provided a custom path for the blacklist. After entering get_blacklist_file, if a blacklist file associated with the passed in genome does not already exist within the grelu blacklists resources folder, an error is thrown and the function can not continue to check if I have provided a path to a custom blacklist file.
Essentially, the logic in filter_blacklist blocks the function from checking if I have provided a custom blacklist. Instead, it only works when users use genomes in the grelu blacklists resources folder. I believe this error would be resolved if the function checked for a custom blacklist first before checking for a blacklist file in the grelu resources.
Thanks!

Thanks for reporting this @varsh7777 . Can you send a pull request?

Fixed in #36


Incorrect ring stereochemistry after embedding

In [1]: from rdkit.Chem import AllChem as Chem

In [21]: mol2d = Chem.MolFromSmiles('[H][C@]1(C[NH3+])CC[C@]([H])(CNC)CC1')

In [22]: for seed in (1, 5):
    print Chem.MolToSmiles(embed(mol2d, seed), isomericSmiles=True)
   ....:
CNC[C@H]1CC[C@@H](C[NH3+])CC1
CNC[C@H]1CC[C@H](C[NH3+])CC1

Making them real chiral centers clears the thing up immediately:
In [23]: mol2d = Chem.MolFromSmiles('[H][C@]1(C[NH3+])OC[C@]([H])(CNC)CC1')

In [24]: smi = Chem.MolToSmiles(mol2d,True)

In [25]: for seed in range(100):
    nsmi= Chem.MolToSmiles(embed(mol2d, seed), isomericSmiles=True)
    if nsmi != smi:
        print nsmi
        print smi
        print seed
   ....:

In [26]:

@greg I think this has been resolved?

Yeah, thanks for catching that.


ci: bump cache & checkout version 4

This PR updates the cache and checkout action to version 4. There are no functional changes.

Thanks!


Add interfaces for RaycastParams and RaycastResult

I've added stubs for these to get rid of the type errors.
It looks like RaycastParams can be constructed, but RaycastResult cannot be. RaycastParams currently doesn't take any arguments, so I suspect it's not enabled yet?