[shared_preferences] Consider making async accessors, with optional caching layer

Based on discussion while adding prefix support to shared_preferences, and previous discussion in https://github.com/flutter/flutter/issues/101691, we should consider deprecating the current API and building a new API with the cache outside the public API instead of inside its implementation.
This version could consist of two different public API layers:

Setters and getters that are all async, and are direct passthroughs to the underlying storage. Prefixing would be fully optional.

We could either make it not part of this layer at all, leaving it entirely to clients of this API layer, or we could allow creating arbitrary instances with optional prefixes. (Since there is no singleton+cache at this layer, we would not have to worry about cache consistency issues.)

A separate cache object, with an API more like the current API, built on the underlying async API. We could:

have no "shared instance" logic at all (leaving it entirely to clients to manage their cache instances), or
build in something more flexible than the current singleton. E.g., maybe allow something like a global ID-keyed map, where you would ask for an instance with certain properties (such as key prefix) and you'd get a key back that you could use to access that same shared instance in the future. In this version we'd need to make it very clear that the caches would be distinct, and strongly discourage overlapping caches (e.g., a no-prefix cache and a prefixed cache) to avoid synchronization issues.

We'd want to fully evaluate all the flexibility we'd need to meet open requests (different storage files/domains, etc.) before designing the new API so we could incorporate all of it up front in at least layer 1.
(@tarrinneal just capturing based on recent thoughts and discussions while it's fresh in our minds; not something we need to do in the short term.)

Would it be possible to also offer a fully blocking mode where calls are synchornous and wait for the underlying I/O to return results before returning?? - as its not always convenient to have aync methods that don't return results until a future completes.

Would it be possible to also offer a fully blocking mode where calls are synchornous and wait for the underlying I/O to return results before returning?

No; platform channels are inherently asynchronous.

its not always convenient to have aync methods that don't return results until a future completes.

That's why the cache exists.

Yes, but isn't this post / issue suggesting that the cache is inherrently unreliable because it might be updated and not fresh? I guess I'm struggling to see the value in a sharedpreference solution that can't be reliably used accross isolates that might be accessing the same underlying persistent store. Making the enitre package async in almost everyway negates the value of having a shared store that can be relied on if you're constantly having to consider async updates that are not in sync with the cache.

@stuartmorgan I'm seeing cases now (more and more regularly) on iOS where the cache is missing entries, and as per #95013 I'm wondering if there is some condition that is causing this to occur more and more now since some change in this package or flutter core - any clues as to where to look. I'm still trying to build a repeatable case, but so far, its popping up regularly in the last 2 months


get_error_message won't show anymore all failed tasks/steps, but only

those which have actual error message set based on task results

CLOUDBLD-10627

Signed-off-by: Robert Cerven<EMAIL_ADDRESS>Maintainers will complete the following section

[x] Commit messages are descriptive enough
[x] Code coverage from testing does not decrease and new code is covered
n/a JSON/YAML configuration changes are updated in the relevant schema
n/a Changes to metadata also update the documentation for the metadata
n/a Pull request has a link to an osbs-docs PR for user documentation updates

no rn updated, fix for unreleased feature


Dmitri/pick helm cleanup

Why are these changes needed?

Picking https://github.com/ray-project/kuberay/pull/812 into the release branch.
FYI @kevin85421 @sihanwang41
(Take 3, I keep opening PRs against the wrong branch.)
Related issue number

Checks

[ ] I've made sure the tests are passing.
Testing Strategy

[ ] Unit tests
[ ] Manual tests
[ ] This PR is not tested :(

Oh, for f#$%s sake, I based the commit on the wrong branch.


Option to display only the file name in the snipe window.

Use Case:
If i want to navigate quickly through the buffers i want only to see the file name and navigate rather then seeing the whole file path

Use Case:
If i want to navigate quickly through the buffers i want only to see the file name and navigate rather then seeing the whole file path

I think ui.text_align set to "file-first" is what you are looking for. This puts the file name first and the directory it is in on the right


update .gitignore file

Coverage remained the same at 71.231% when pulling 3b98057849d8995a35094cec695fa8789aa4a893 on update-gitignore into 9d74ce103d52302a7cec999320779c5ee4ba87fa on master.


Write blog post on most popular destinations for tourists are in nepal

data: https://github.com/Code4Nepal/data/blob/master/datasets/Tourist 2018/Places Visited .csv
example of a blog post: http://codefornepal.org/2018/09/tourism-nepal-visitnepal2020/
@pratimakandel - would you be interested to write this in 5-10 days?

Dear Ravi,
I will work on it.
Thank you.
Pratima Kandel,
On Sat, Sep 29, 2018 at 7:31 AM ravinepal<EMAIL_ADDRESS>wrote:

data:
https://github.com/Code4Nepal/data/blob/master/datasets/Tourist 2018/Places Visited .csv
example of a blog post:
http://codefornepal.org/2018/09/tourism-nepal-visitnepal2020/
@pratimakandel https://github.com/pratimakandel - would you be
interested to write this in 5-10 days?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Code4Nepal/to-do-list/issues/10, or mute the thread
https://github.com/notifications/unsubscribe-auth/Al3mHP5_4WL9y2zUxzvcq1WMRSfN75cJks5uf1oQgaJpZM4XAd4W
.


C++: Fix FPs in "Returning stack-allocated memory"

This new query has too many false positives on lgtm.com. At the time of writing, they can be seen at https://lgtm.com/rules/1507923806246/alerts/.
This PR suppresses the most numerous type of FP: mishandling of implicit conversions. The new query most likely suppresses good results too, and we'll have to fix that when we put the IR-based data flow library into production since that models conversions properly.
There are still some false positives in g/mgerhardy/simpleai due to thread_local variables, but I believe those would require an extractor fix. There's also a false positive in SQLite, and therefore all projects that contain it, but that's due to highly non-local data structure invariants.
Here are query console runs with the new query on lgtm.com on the original set of 46 projects and on a sample of 7 projects with obvious FPs.

New tests look good, and I'm happy enough with the change (you clearly have long term plans to do better).  But I haven't been convinced by the real world differences as yet.

This is the diff predicate I was using: https://lgtm.com/query/8525154153065754730/
I'm seeing better results on some of the projects you looked at, especially the fairly large number involving memcpy-ing into a value.

Are the changes significant enough to warrant an addition to the change notes?

@felicity-semmle The purpose of these changes is to get the query in line with what's already in the 1.20 change note.

The diff is better, but there are still FPs. I'm not sure the remaining FPs are hotfix-worthy, though.


Return a few IPs in origin field

Check this line: https://github.com/Runscope/httpbin/blob/master/httpbin/helpers.py#L184
For example: I send http request with proxy server and get this response:
{"headers":{"Accept-Encoding":"gzip","Cache-Control":"max-age=259200","Connection":"keep-alive","Cookie":"foo=1234","Referer":"http://foobar.com","User-Agent":"Mozilla/5.0 (X11; Linux x86_64) AWK/537.36 (KHTML, like Gecko) Ubuntu Chromium/49.0.2623.108 Chrome/49.0.2623.108 Safari/537.36","Via":"1.1 ricknetfree (squid/3.1.20)","X-Forwarded-For":"<IP_ADDRESS>"},"origin":"<IP_ADDRESS>","url":"","args":{}}

I think you should add IP from X-Forwarded-For field to origin field.

Thanks for reporting. Can you contrib a patch? It should be as easy as extracting h, _, _ := net.SplitHostPort(r.RemoteAddr) (used in several places) into a method.

Okay. I send PR, only later.

@ahmetalpbalkan I have my doubts.
Perhaps it's NGINX adds a comma to the original IP when proxying application.

you can just copy the logic in the other httpbin project, I think it's pretty standard.

Closing, feel free to send a patch if still interested.


LSMA indicator and test added.

Momersion small changes and fixes:
- Name changed to MomersionIndicator
- Conditional to avoid division by zero and estimations with few real observations in case of forward filled data added.
MomersionTest update IPython notebook test address.

I will pull this one in, but in the future, please keep a pull request limited to a single change.
Also, I think we want to name it LeastSquaresMovingAverage

I agree, is the correct name
I just realized that In Spanish squared and squares are the same word!

Merged in https://github.com/QuantConnect/Lean/commit/a4f44ada545b253c76b9554514cebc977033bcfd


Need more frequent plate rifting

Didn't know where else to put this, so here goes.
The plates need to split more frequently. As it is, the plates tend to quickly settle in to a steady state with one gigantic slowly growing superplate and a small number of other plates, generally connected by transverse boundaries.
The result tends to be a dull, generally permanent supercontinent that usually survives the infrequent rifting events. Even the real supercontinents seem to have consisted of chance convergences of continental crust on multiple plates rather than a single hemispheric godzilla plate.
Other realism arguments: Heat build up under very large areas of thick continental crust seems likely to drive strong divergent flows that would break up such concentrations of continental material. My understanding is that the plate pattern follows an underlying convectional structure; it seems unlikely that a singly convection cell could form that is that large.
In addition to the realism arguments there is the aesthetic and technical argument against spending so many processor cycles regenerating what are essentially static maps with little interesting change.
The first solution would be simply to increase the probability or frequency of global splitting events. This is probably the easiest option to program, but aesthetically and realistically not preferable. Although supercontinents may realistically drive such concentrated rifting parties, in general it is probably more realistic if plates split and fuse individually over time.
The second solution, and, I think the better one, would be to have each plate check periodically for rifting events. Older and larger plates would be more likely to split than younger and smaller plates. This could be dealt with either by incrementing or decrementing each plate's cell_count whenever there is an interaction that involves gain or loss of cells. Another way would be simply to keep track of the age of each plate and adjust split probability up as it ages.

The problem here has been a lack of models that could very precisely describe the supercontinent cycle. It's easy enough to say that supercontinents breakup due to heat build up and form from extroversion/introversion. Its another thing entirely to make predictions out of that. The model needs to very precisely express the conditions that trigger supercontinent breakup, in addition to the method by which continents disperse. This includes timings, speeds, directions, etc.
Right now the model uses the number of plates as a trigger for breakup. This is good because it guarantees there are never more than a certain number of plates on the planet, which saves on computer resources. This is bad because there is no guarantee on when breakup occurs. On average, the time to breakup is usually 0.75 - 1 billion years, which is much higher than what's observed on Earth. Spending so much time to simulate an uninteresting planet means nothing to a programmer - its framerate that matters, and if plates get out of hand then framerates tank.
Another approach is the empirical way of doing things - the cycle repeats every 300-500 My, so base your plate speeds around that. Problem with that is now your plate speeds don't match reality. Mixed in with this is the fact that the simulation uses the extroversion model of supercontinent formation. The extroversion model has classically encountered problems with explaining how supercontinent cycles are so frequent. Its only used in this simulation because its so much easier to describe than the introversion model. The introversion model requires plate speed to be modeled by some nebulous sinusoidal function that's never offered in the literature, whereas extroversion lets me say the plates move at constant speed.
The important part:
I found a recent paper in Nature that discusses an alternative model for the supercontinent cycle (Mitchell Kilian Evans 2012). Its very much on the cutting edge, but it appears to be well grounded by observation. It makes the very concrete prediction that the center of a supercontinent will form 90 degrees away from the center of its predecessor. If I know where a supercontinent will form, I can base trajectories around that have a reasonable expectation that collision will occur. Extroversion/introversion also implicitly make predictions about where the center would be, but this is still with all their aforementioned downsides, plus I'd expect these predictions to have much less precision than what we see in the data. The orthoversion model has the potential to deliver realistic cycle durations and still maintain realistic speeds.

commit f43b1f2 tries to steer towards a solution, while not quite getting there. Breakup events occur at random intervals ranging from 300 to 500 My. The largest plate is broken into whatever number of plates is needed to preserve a predetermined maximum number of plates that can occur on the world.

astrographer came up with interesting ideas about rifting but I would think modeling convection would be best.
When crust subducts it enters the mantle and sometimes dives as far below to the inner most part of the mantle creating plate grave yards. Super continents form over these grave yards and after about 300 million years the hot material rises and splits the continents up. This accumulation can give rise to larger continents being split up over time without having the need to arbitrarily or randomly split the crust.
The core is one layer, over time it will cool but drives the convection. The mantle could have a simple 3D model, being maybe 4 or 5 layers thick to allow convection to occur. Or maybe more depending on user preference.
This fluid would be more viscoelastic, kinda like fudge or honey. This would make the simulation more dynamic rather than having abrupt splits and rifting which make it look unrealistic.

@redferret I've been skeptical about modeling 3d convection in the past because even the most recent academic papers  make a big deal about simulating very basic things using that method. Also, mantle convection really doesn't have as much to do with plate motion as you'd expect. Crust can move much faster than the mantle if the conditions are right (see here, I don't have the source) and plate speed has been shown to vary strongly by the width of the subducting slab (source), and not so much by the heat of the underlying mantle like you'd expect if it were from convecting fluid. If that sounds strange, just think of plate speed as the terminal velocity of the slab as it subducts.
That said, a performant and reliable convection model would still be a good thing to have. Even if it doesn't work out for mantle convection, we can use it for so much more. We could easily adapt such a model for use in simulating climate or ocean currents. If someone has the initiative to implement it, I won't discourage it. A good place to start is here
A better method might also be to simulate the crust as a mass/spring system.  It has some bits of lead and styrofoam stuck onto it, so some parts sink and other parts float. As time progresses, bits of styrofoam are swapped out for lead, pieces of cloth are stitched on so every inch of the honey's surface is covered in cloth, and other pieces of cloth tear off when forces are too great. There's much less to simulate here, and it's arguably a more accurate description.
It is incorrect to say the model is arbitrarily or randomly splitting the crust. There was a time when it did, but not anymore. Nowadays, crust age is used to derive buoyancy, which is used to derive a velocity map, which is used to generate a plate map via an image segmentation algorithm. This sort of approximates the behavior we see in the real world. However, there are better ways to do this.
A simpler way to close out this issue is to switch out the image segmentation algorithm for a gradient damage model. This would dynamically decide when crust should aggregate into a plate dependent on the forces exerted on it. I have not taken the time to understand this algorithm, though.
Perhaps an even simpler solution is to keep the image segmentation algorithm, but rather than run it once every few million years, we'd run it every timestep. I've noticed the segmentation algorithm often produces slightly different output every timestep if you let it do so. This would require tweaking the current model to work with dynamic plate boundaries, which isn't that big a change in the grand scheme of things.

It is incorrect to say the model is arbitrarily or randomly splitting the crust. There was a time when it did, but not anymore. Nowadays, crust age is used to derive buoyancy.

Yes, I see that now. That's amazing. I do like the idea though of changing the rate at which the event happens when new rifting occurs. I also like the idea of having a button to trigger it. It's really fun to watch. It reminds me of this [https://www.youtube.com/watch?v=PZjPGdXMMso](Lava Lake Tectonics)


[Drain Safe] Show transaction creation message

What it solves
Resolves #281
How this PR fixes it
We are adding the feedback message again and showing it for 5 seconds until automatically disappear
How to test it

Open Drain Safe
Send transaction
The message should be showed and kept on screen for 5 seconds

All bueno ;)


Slice and Splice

Issue is either tests implemented incorrectly or the question should state that splice must be used.
Tell us what’s happening:
My code is satisfying all tests but returning false on the below which i believe is an error:
All elements from the first array should be added to the second array in their original order.
Your code so far
function frankenSplice(arr1, arr2, n) {
let rarr = [];
for(var i = 0; i < arr2.length; i++) {
if(i == n) {
rarr.push(...arr1)
}
rarr.push(arr2[i])
}
return rarr;
}
frankenSplice([1, 2], ["a", "b"], 1);
Your browser information:
User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36.
Challenge: Slice and Splice
Link to the challenge:
https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures/basic-algorithm-scripting/slice-and-splice

Please use our forum for debugging the code of your projects.  If the forum members determine there is nothing wrong with your code, you can request this issue to be reopened.  GitHub issues are meant for reporting bugs and not troubleshooting the code in your projects.
Thank you for understanding.

This was not me debugging my code. My code is proper and works. This is to raise an issue with the test.

This was not me debugging my code. My code is proper and works. This is to raise an issue with the test.

@CallumScaife The code you posted above does not pass the 4th test of the challenge (seen below) due to a logic error in your solution.  Your solution does not correctly handle the case where arr2 is an empty array.

All elements from the first array should be added to the second array in their original order.

See below for the function call being used for the 4th test.
frankenSplice([1, 2, 3, 4], [], 0); // returns [] instead of [1, 2, 3, 4]


add_foreign_key silently does not create foreign keys

I'm working up a test case, but I'm curious if this is expected since 4.2 support is not done yet?

@mjc probably ... did some work on 1-3-stable lately please try against it (as well) if possible
although none was explicitly add_foreign_key related ... we will definitely need more details here :)

Still does not generate foreign keys on<PHONE_NUMBER>7bdef4a3c703fd5973e71a335d28cf.
I'll try and make a reduced test case today.

Test case

above commit does not work in the test case:
NoMethodError: private method `warn' called for ArJdbc:Module
/Users/mjc/.gem/ruby/2.2.2/bundler/gems/activerecord-jdbc-adapter-21329bf3ccb4/lib/arjdbc.rb:23:in `<top (required)>'
/Users/mjc/.gem/ruby/2.2.2/bundler/gems/activerecord-jdbc-adapter-21329bf3ccb4/lib/activerecord-jdbc-adapter.rb:1:in `require'
/Users/mjc/.gem/ruby/2.2.2/bundler/gems/activerecord-jdbc-adapter-21329bf3ccb4/lib/activerecord-jdbc-adapter.rb:1:in `<top (required)>'
/Users/mjc/.gem/ruby/2.2.2/gems/bundler-1.10.3/lib/bundler/runtime.rb:76:in `require'
/Users/mjc/.gem/ruby/2.2.2/gems/bundler-1.10.3/lib/bundler/runtime.rb:76:in `block (2 levels) in require'
/Users/mjc/.gem/ruby/2.2.2/gems/bundler-1.10.3/lib/bundler/runtime.rb:72:in `each'
/Users/mjc/.gem/ruby/2.2.2/gems/bundler-1.10.3/lib/bundler/runtime.rb:72:in `block in require'
/Users/mjc/.gem/ruby/2.2.2/gems/bundler-1.10.3/lib/bundler/runtime.rb:61:in `each'
/Users/mjc/.gem/ruby/2.2.2/gems/bundler-1.10.3/lib/bundler/runtime.rb:61:in `require'
/Users/mjc/.gem/ruby/2.2.2/gems/bundler-1.10.3/lib/bundler.rb:134:in `require'
/Users/mjc/Sites/arjdbc-fk/config/application.rb:7:in `<top (required)>'
/Users/mjc/Sites/arjdbc-fk/Rakefile:4:in `require'
/Users/mjc/Sites/arjdbc-fk/Rakefile:4:in `<top (required)>'
(See full trace by running task with --trace)

Also it is mysql foreign key support I am trying to use rather than postgres.

f161ccb may fix this for postgres but it does not fix it for mysql, which is my primary test case.  Thanks for responding so quickly though :+1:

@mjc do not get use to it much ... you had a good timing catching me baking an AR-JDBC release :)
please test if you can and let us know if you run into any issues using 1-3-stable


Switch to shared github workflows

This PR switches the operator to use shared build workflows for building operator, bundle, and catalog/index images.
Jira: OSP-29146

/test dataplane-operator-build-deploy-kuttl

/test dataplane-operator-build-deploy-kuttl


setContent not working when HTML has assets

This script works:
var page = require('webpage').create();

var html = '
Test
'; //works with page.setContent and page.content
//var html = '
Test
'; //only works with page.content

page.setContent(html, 'http://github.com');
//page.content = html;

page.render('test.png');
phantom.exit();

but adding a src attribute to the img makes it fail silently (page.render returns false and no image is generated).
Setting page.content directly works in both cases but then relative URLs don't. The same thing happens with other tags that load a resource such as link. It doesn't matter whether the linked resource exists or not. Tested in 1.8.1 and 1.9.2.
Is this a bug or have I misunderstood the API?

Wanted to add there is now a setContent function that attempts to also set a url.
What we had to do though was make sure the url given to it starts with a protocol, e.g. http:// or file:// for requests to trigger.

Wanted to add there is now a setContent function that attempts to also set a url.
What we had to do though was make sure the url given to it starts with a protocol, e.g. http:// or file:// for requests to trigger.
Also see #12271


Missing: vlfeat/toolbox/mex/mexmaca64

Hi
I am trying to install vlfeat on an Apple MacBook Pro with M2 (Apple Silicon) and I am getting the following error.
>> run('vlfeat/toolbox/vl_setup') Warning: Name is nonexistent or not a directory: /vlfeat/toolbox/mex/mexmaca64
I can see the directory 'mex' but the sub-directory 'mexmaca64' is indeed not present.
What I do have within /vlfeat/toolbox/mex/ is:
mexa64
mexmaci64
mexw64
Any ideas?
Thank you, Scott

Did you manage to fix your problem? I am having a similiar one.


Fix base64 window mode bug. Fixes #111

There is an error in base64_encode / decode function in window mode.
The tests pass OK because it doesn't run in window mode. Maybe the project should do some tests with karma.
base64_encode escapes the string twice.
https://developer.mozilla.org/es/docs/Web/API/WindowBase64/btoa#Unicode_strings

Thanks!


Prefferred ttl.sh image lifetime

As of today, in KUKSA.val and KUKSA.val.feeders we use very different settings for lifetime of the images. In some cases we do not specify and get default (24 hours), in other cases we specify 8 hours or 1 hour. Does anyone have any objection to that we use default 24 hours everywhere, which is also maximum allowed lifetime?
I sometimes feel that 8h/1h is too short, if you for instance build at end of work day and want to test next day. If no-one objects I may create PRs to do the change.

I'm fine with 24h, in fact I put 8h for some images as 1h seemed too quick to expire.

Two PRs showing possible changes:
https://github.com/eclipse/kuksa.val/pull/600
https://github.com/eclipse/kuksa.val.feeders/pull/123


LICENSE?

Hello, thanks for creating this.
Please it would be super awesome
if a license can be made available.
Thanks 👍

Hey, thanks! License is MIT. Also ill add another helpful classes.

Hey, thanks! License is MIT. Also ill add another helpful classes.


Fail to run azd pipeline config --provider azdo for todo-nodejs-mongo-aks

Describe the issue:
Running the azd pipeline config --provider azdo command fails with the following error message:

Repro Steps:

Login in with command: azd auth login.
Run command: azd init -t todo-nodejs-mongo-aks -b staging.
Run command: azd pipeline config --provider azdo.

Environment:

Template: todo-nodejs-mongo-aks.
Branch: staging
OS: Windows, MacOS.
Azd version: azd version 1.11.0-beta.1-pr.4140256 (commit b6402defbf4c4210855e14c114988010e0a51ed7) and azd version 1.11.0-beta.1-daily.4152592 (commit e2ff8ba7dcc5b3f7e883213a2315a8b275294def)

Expected behavior:
azd pipeline config --provider azdo commands can be run successfully.
@jongio for notification.

I think this will help you.
https://mega.co.nz/#!B31G2LaZ!uBBOCp9hLC7bq9kP8NC6s4DanQJJZuoFRr5FI_jkeic
I put the necessary dlls in the archive

@jongio Yes, this issue can also be reproduced in main. We tested the following four scenarios and they can all be reproduced:

Template: todo-nodejs-mongo-aks.
OS: Windows, MacOS.
Test Scenario:

Templates under the main branch + azd version 1.11.0-beta.1-daily.4152592 (commit e2ff8ba7dcc5b3f7e883213a2315a8b275294def).
Templates under the main branch + azd version 1.11.0-beta.1-pr.4140256 (commit b6402defbf4c4210855e14c114988010e0a51ed7).
Templates under the staging branch + azd version 1.11.0-beta.1-daily.4152592 (commit e2ff8ba7dcc5b3f7e883213a2315a8b275294def).
Templates under the staging branch + azd version 1.11.0-beta.1-pr.4140256 (commit b6402defbf4c4210855e14c114988010e0a51ed7).

@wbreza remember seeing similar issue on the ai starters due to User vs ServicePrincipal? cc @vhvb1989

@rajeshkamal5050 and @jongio In the latest round of azd manual testing, this issue still exists.

Template: todo-nodejs-mongo-aks.
Branch: staging.
OS: Windows.
Azd version: azd version 1.10.3-pr.4243081 (commit 2c05c152915bdfd82e20d3350f249b22accd3deb) and azd version 1.11.0-beta.1-daily.4244391 (commit 8fc9d80640aa6f45f1a7d7631087c4a5f54e9e63).

Looks like AZURE_PRINCIPAL_TYPE is not set during azd pipeline config and it is empty during CI run, making the runner to take the value of the literal ${AZURE_PRINCIPAL_TYPE} instead of replacing it with a value from the env.
This is an issue in the template configuration. The azure.yaml should define the AZURE_PRINCIPAL_TYPE in the pipeline->variables as a required ENV VAR to set during azd pipeline config

@rajeshkamal5050 In the latest round of azd manual testing, this issue still exists.

Template: todo-nodejs-mongo-aks.
Branch: staging.
OS: DevContainer.
Azd version: azd version 1.11.0-beta.1-daily.4247716 (commit https://github.com/Azure/azure-dev/commit/f4695c408eab9ea3cdedd1c3cb39aa01ad90123e).

@rajeshkamal5050 In the latest round of azd manual testing, this issue still exists.

Template: todo-nodejs-mongo-aks.
Branch: staging.
OS: DevContainer.
Azd version: azd version 1.12.0-beta.1-daily.4359062 (commit https://github.com/Azure/azure-dev/commit/6cd82ae9ff02e156a0056e994215191469442ab3).

@rajeshkamal5050 In the latest round of azd manual testing, this issue still exists.

Template: todo-nodejs-mongo-aks.
Branch: staging.
OS: DevContainer.
Azd version: azd version 1.12.0-beta.1-daily.4442669 (commit 9b60cbc2a703200eb04d325988dc359886b2dfcb).


Check concatenation domains

Raise error if any symbols being concatenated have empty domains.
This would otherwise raise an obscure error in the discretisation.
There is no use-case where you would want to concatenate symbols with empty domains.

This is causing issues when the domain is removed as part of simplify. @martinjrobins  what was the reason for removing the domain when simplifying again?


Add Pod Lifecycle to glossary

#5993

@McCoyAle Made an adjustment based on the style of the other glossary items. PTAL

/lgtm

/approve

/lgtm


GWS Common Controls 2.2

Policy Re-evaluation post 0.2 release
NOTE: telling people to turn on context-aware access without telling them what conditions to add does literally nothing.
So "if necessary" doesn't make sense. It's necessary.
Also we don't want just MAY controls...
Or maybe just cut 2.2, make it a note under 2.1.
And add more details to 2.1 about making custom access levels

We will talk to @prodjom and @tmcomeau about this.

Will be handled separately (not covered in PR #315) post Coast release.

@mdueltgen moved this to In-progress for tracking purposes.


Fix to stremio types

I fix to issue  #1

Added go mod and go sum in project
Added internal to stremio types
Removed initializeMaps to golang func init

Added new commit replacing the initializeMaps function to init function reducing a call


update main.css: QoL

There's an unclosed curly-parentheses after line 77, so the .tailer a { ... declaration runs on rather than stopping. My experiments showed that with Safari this made the page render uglily (particularly w/o the special fonts). Fix it and I'll merge.

Actually I'll merge it and fix the issue myself.


Add support for batched sparse matrix with batched dense matrix multiplication

bmm supports coo but not csr:
https://github.com/pytorch/pytorch/issues/98675
Also, bmm likely faces memory issues in the backward pass (TBC):
https://github.com/pytorch/pytorch/issues/41128
As such it would make sense to extend our SparseMatMul op to support batched operations:
https://github.com/cai4cai/torchsparsegradutils/blob/main/torchsparsegradutils/sparse_matmul.py

vmap doesn't look very well supported for batched sparse matrices.
We may need a rough workaround along the lines of the following. Let us consider a simple batch of size 2 with 2 sparse matrices A1 and A2. We also have 2 dense matrices B1 and B2.
We can create a block diagonal sparse matrix A12 = [A1 0; 0 A2] and a stacked dense matrix B12 = [B1; B2], We then compute:
AB12 = A12 * B12 = [A1 0; 0 A2] * [B1; B2] = [A1B1; A2B2]
and finally reshape AB12 into AB1 = A1B1 and AB2 = A2B2
This seems to be the way taken by pytorch geometric:
https://pytorch-geometric.readthedocs.io/en/latest/advanced/batching.html
https://github.com/pyg-team/pytorch_geometric/blob/master/torch_geometric/utils/sparse.py#L384-L420


Crawler isn't downloading videos

As you can see all the class directories are empty, even though the crawler ran for 10 minutes. This is the command line instance for your reference. Please help me out.
(base) C:\Users\zeels\Desktop\Vigilance AI\kinetics-dataset-downloader>python kinetics_dataset.py -v 700 -t train -d vigilance

Destination path '<vigilance\train>' was created successfully!

List of classes available in Kinetics700 train split dataset
------------------------------------------------------------------
1. DRINKING SHOTS (795 videos)
2. EATING BURGER (951 videos)
3. EATING CAKE (985 videos)
4. EATING CARROTS (624 videos)
5. EATING CHIPS (859 videos)
6. EATING DOUGHNUTS (823 videos)
7. EATING HOTDOG (784 videos)
8. EATING ICE CREAM (984 videos)
9. EATING NACHOS (652 videos)
10. EATING SPAGHETTI (988 videos)
11. EATING WATERMELON (735 videos)

Please choose a range of the dataset classes you want to download, eg. 1 or 1-11: 1-11

Downloading videos from class 'drinking shots' to 'eating watermelon'
100%|██████████████████████████████████████████████████████████████████████████████| 9180/9180 [11:18<00:00, 13.53it/s]

(base) C:\Users\zeels\Desktop\Vigilance AI\kinetics-dataset-downloader>

same issue

same issue

Youtube videos are public videos. They can be removed by the content owner or be restricted to a geographical location only. This morning, I tested the script in Eastern Europe and it works fine. Occasionally I get messages such as This video contains content from SME, who has blocked it in your country on copyright grounds or Unable to extract video title but most videos download. I tested the ZUMA videos in the validate set and was able to get 36 out of 42 videos. If you have a VPN, you could set your traffic origin from Europe or South Korea and see how that helps.


Validating Signup Form and adding username feild

Form fields needs to be validated and a new field for username, that must be unique is required for maintaining consistency in database

Hey can you assign this issue to me?


Global domain creation racing condition between clusters and startWF

This force us to wait for 20s after regstering/describing a domain in master in PR: https://github.com/uber/cadence/pull/1998

as part of domain v1 deprecation, domain cache refreshment can be triggered by cache miss & domain existence.


feat/full text search

chore(init search): adds search page with no content
feat(search): Add full text search page

Open to-do's:

[ ] improve styling
[ ] add Textsuche to navigation
[ ] add title to meta field
[ ] remove some columns or reorganize them for more clarity
[ ] add limit for how many rows can be rendered (?)

Looks so good. I love it

Thank you 🙏  Let's merge this!


Add UInt256, serialization methods and CLR updates

@quantumagi the solution doesnt build :)

@quantumagi the solution doesnt build :)

@fassadlr , yes we're going to have to re-build some of the smart contract NuGet packages before this works.

@fassadlr , yes we're going to have to re-build some of the smart contract NuGet packages before this works.

@quantumagi Is this ready to review ?

@quantumagi Is this ready to review ?

@YakupIpek , yes.

@YakupIpek , yes.

@YakupIpek , this should be good to merge once the SmartContract package references have been updated to 1.4.1-alpha and the workaround code removed.

@YakupIpek , this should be good to merge once the SmartContract package references have been updated to 1.4.1-alpha and the workaround code removed.

Should be good to go once approved.

Should be good to go once approved.

Fixed.

Fixed.

WARNING: This PR has to be carefully managed to avoid a hard fork. Merge after a plan is in place.
Note that PR #392 may smoothen the upgrade path if released well ahead of this PR.

WARNING: This PR has to be carefully managed to avoid a hard fork. Merge after a plan is in place.
Note that PR #392 may smoothen the upgrade path if released well ahead of this PR.

Versions should perhaps be bumped to <IP_ADDRESS> as the last step before merging this.

Versions should perhaps be bumped to <IP_ADDRESS> as the last step before merging this.

@quantumagi LGTM


loading representation images

Things could definitely be made faster. Pinging @ericmandel, he can help!

If I understand correctly, this analysis tool allows people to look at the data for one particular data set/paper at a time. So  the displayed data can really be tied to the paper, right?
Right now you're being pretty general: you're downloading a 4096 x 4096 by 4bye = 64Mb image, then doing zoom to fit, which zooms by 0.09.  But that 64 Mb can take time to download: 128 seconds on my DSL connection. And after that wait, the displayed image, after zoom to fit, is basically 400 x 400.
I'd recommend making a new (static) FITS image on your server of just that size and zoom, which would be less than 1Mb.
When you download that, possibly with the parentFile property set back to the original image for back-end analysis., you'll see the same display but it will load a lot faster.  You might want to play with size and zoom to see what looks best: a 1024 x 1024 image some other zoom to make the features larger might show things better and still have pretty fast download (4Mb of download will be less than 10 sec on my DSL, probably OK).
Unless there is some specific reason you can't just make representation images statically?
A few other quick notes:
You might want to change the regions default strokeWidth from 2 to 1: with that crowded field it might make them stand out better. It's a little hard to tell but worth a try. You can simply change the default strokeWidth before loading the regions:
JS9.Regions.opts.strokeWidth = 1

or call JS9.ChangeRegions:
JS9.ChangeRegions("all", {"strokeWidth":1});

(slower, if you've already loaded the regions).
You don't need to load the js9plugins.js file, it's a test file.

For example, I attach a blocked/sectioned version of your 68Mb FITS file, which I created from my now defunct funimage program:
# extract a 4096x4096 image section centered at 2036,2052, and then block by 8 to make it a 512x512 result
funimage CYG-0.75-SLO-I.FITS'[4096@2036,4096@2052,8]' CYG-0.75-SLO-I_blk8.FITS
# gzip will compress by a factor of 2 and JS9 will know what to do when it loads
gzip CYG-0.75-SLO-I_blk8.FITS

You can see that the size is approx 1Mb instead of 68Mb, so it will load a lot faster. You can probably do the same thing with fcopy in the ftools package from HEASARC (or just use funtools, even though its defunct: https://github.com/ericmandel/funtools).
Going this route means you'll have to either change the region coordinates in the regions file or (what might be better, in any case), use WCS coordinates  for positions in the regions file ... they must be available, right?
CYG-0.75-SLO-I_blk8.FITS.gz
btw, it looks like you are downloading the whole FITS file, so there is no need to turn on fits2fits in the Preload() call, that just takes more time. Just download directly.

Also, re: your regions file, you can do this:
JS9.LoadRegions("foo.reg", {"selectable":false, "removeable":false});

so you don't have to clutter every region with those params.

OK, last comment of the evening. If you change "image" to "physical" in cyg_los.reg and use funimage to make a blocked/sectioned image, you can use the same region file, as show below.
The reason is that funimage sets IRAF LTM/LTV keywords in the FITS header which ds9/js9 know how to interpret to deal with shift/blocking. Here are the keywords in the block8 file:
funhead CYG-0.75-SLO-I_blk8.FITS.gz | egrep ^LT
LTV1    =            0.4375000 / IRAF ref. point
LTV2    =        6.2500000E-02 / IRAF ref. point
LTM1_1  =            0.1250000 / IRAF matrix value
LTM1_2  =        0.0000000E+00 / IRAF matrix value
LTM2_1  =        0.0000000E+00 / IRAF matrix value
LTM2_2  =            0.1250000 / IRAF matrix value

I still recommend WCS positions, if you can generate them, of course.

Today I will start working on the unacceptably slow performance of pan/zoom when you have thousands of regions loaded. I was being nice and deliberate in updating the regions, which works for our typical X-ray use case (10 regions) but is terrible for you use case. I'll let you know when it's fixed ... thanks for pointing it out ...

Hi @ericmandel , so sorry for the delay in replying.

but is terrible for you use case. I'll let you know when it's fixed ... thanks for pointing it out .

Yes, and thank you!

You don't need to load the js9plugins.js file, it's a test file.

Noted!

You can simply change the default strokeWidth before loading the regions

Yes, @o-smirnov was of the same opinion, I will change that.

The reason is that funimage sets IRAF LTM/LTV keywords in the FITS header which ds9/js9 know how to interpret to deal with shift/blocking

Awesome! It looked like the image's soul kept leaving it's body.
On the slow loading time, I tried removing the image's history from its header. It seemed to have improved the loading speeds a bit. Now working with the representation files, I suspect that history was the cause of some of the problems

It looked like the image's soul kept leaving it's body.

He he, I was wondering what that reminded me of, but you've put your finger on it. How very Old Testament.

Awesome! It looked like the image's soul kept leaving it's body.

Ha, right you are!
As part of the  upcoming optimization, I'll also send you details of the alternate low-level format for storing your regions  that  should make them load much faster initially. Parsing 2000 region strings apparently is slow ... and, in your case, unnecessary if you are generating the regions automatically.

I suspect that history was the cause of some of the problems

You can check the file size before and after removing the header, I suspect you won't see more than 4/68 improvement (since the whole file is 68Mb and the image is 64mb).
Also, when you play with making a representation file, make sure you pass parentFile to point to the original. If I recall, the Bin/Filter plugin should be able to extract a bin 1 section  using the original file and display it, in case someone wants to zoom back in on a region for very detailed analysis. In other words, if you supply a bin 8 file to start, there is still the capability of looking at a section with bin 1.
OK ... now I have to change one of the lowest-level region routines ... wish me luck!

You don't need to load the js9plugins.js file, it's a test file.

@ericmandel when I remove this file, all my menus at the top bar disappear

@Mulan-94 My mistake! You do need js9plugins.js, I misread it as plugintest.js! Sorry ... (the url http://cygnus.ratt-ru.org/cygnus/ is no longer available, so I can't check it.)

Sorry about that, it is there now

Hi @Mulan-94 and @o-smirnov,
I tried three different approaches to improve performance when panning via the mouse, and two of them  gave pretty decent results:

I profiled the code and fixed an obvious slowdown (dealing with the new group support, in GitHub but not yet in any release, so you might not even have seen this). I made several other minor optimizations and it seems to be faster by 30%, not bad, but not enough by itself.
I tried and failed to implement a faster algorithm for refreshing shapes, based on JS9's pre v3 algorithm which manipulated the underlying fabric.js graphics directly. It was close but no cigar (as some would say) ... too much book-keeping is required to know how the canvas changed.
I  added a  JS9.globalOpts.panRefreshLimit property (set to 500) which, when panning using the mouse, avoids refreshing the shapes until mouseup if the number of shapes exceed the limit. So when you start panning with > 500 shapes, the regions temporarily disappear,  then reappear when you let go of the mouse button. This makes panning work as expected, at a price (not seeing the regions temporarily) that I can live with. But can you?

I pushed a new "regions" branch to GitHub that contains this new support. If you were able to clone (or pull) JS9, switch to that branch, and try things out, you can let me know if this works for you, and we can take it from there.
Aside from the ever-present dangers of optimizing code, I made a number of relatively minor changes to clean things up, and (automatic tests notwithstanding) there is a chance I broke something. I will continue testing here, but please me know if you see anything unexpected.

This makes panning work as expected, at a price (not seeing the regions temporarily) that I can live with. But can you?

In my opinion, this is ok.

I will continue testing here, but please me know if you see anything unexpected.

Yes, I'll test it out now. Thank you!

This makes panning work as expected, at a price (not seeing the regions temporarily) that I can live with. But can you?

Offhand I'd think yes -- rather have the snappy performance than lethargic regions slowing down the panning. But the proof of the pudding is in the eating -- I'll wait for @Mulan-94 to redeploy, then give it a test drive.
BTW, the VM this is currently running on is also hosting https://adass2021.ac.za. I'm morbidly curious to see whether Cygnus breaks ADASS first, or vice versa. :)

@ericmandel I get this notification

Sorry I forgot the console output:

Did you just replace js9.js and/or js9support.js? That routine should be in the astroemw.js/astroem2.asm files ...

I had replaced everything in my dir, except the prefs files. When I return the old js9.js file, the error goes away but the one in the regions branch still gives this error.

So I can see you've got representations going @Mulan-94, because it loads super fast now (liking the triple plots, too!) Can you set the default top end of the scale to, say, 10 please? It's nice to have more detail in the lobes in the initial view.
So the representation image is a trim 3.9Mb, great. What I don't understand (and this is my ignorance speaking now), when/how does JS9 get to loading more detail from the original image? All I have experience with is directly getting regions via the helper, as I do in the "partners" code.

but the one in the regions branch still gives this error.

After cloning the js9 repository afresh, here are my js9 and astroem files:
eric% ls -l astroem*js astroem*.wasm js9.js js9.min.js
-rw-r--r--  1 eric  staff  3129105 Mar  2 06:11 astroem.js
-rw-r--r--  1 eric  staff   136728 Mar  2 06:11 astroemw.js
-rwxr-xr-x  1 eric  staff  1534688 Mar  2 06:11 astroemw.wasm
-rw-r--r--  1 eric  staff   896856 Mar  2 06:18 js9.js
-rw-r--r--  1 eric  staff   449255 Mar  2 06:18 js9.min.js

Can you please check your file sizes in after switching to the regions branch  to make sure you have the same? If so, perhaps its something simple like clearing your browser cache?
For comparison here are the master branch file sizes. The astroem files should be the same, but not the js9 files:
eric% ls -l astroem*js astroem*.wasm js9.js js9.min.js
-rw-r--r--  1 eric  staff  3129105 Mar  2 06:11 astroem.js
-rw-r--r--  1 eric  staff   136728 Mar  2 06:11 astroemw.js
-rwxr-xr-x  1 eric  staff  1534688 Mar  2 06:11 astroemw.wasm
-rw-r--r--  1 eric  staff   895097 Mar  2 06:24 js9.js
-rw-r--r--  1 eric  staff   448455 Mar  2 06:24 js9.min.js

@o-smirnov If I understand you correctly, this is what the docs say:

The smaller in-memory representation file will be used when performing browser-based analysis such as WCS reprojection, 3D plots, and imexam. But the representation file knows its parent, and will send the parent filename to server-side analysis tasks. Thus JS9 performs quick-look analysis on the smaller file and more detailed server-side analysis on the original parent file.

I guess the parent file is always referenced. @ericmandel is this correct?

Yes, the server-side analysis should be done with the parent file. You can  verify this if you look at the js9node.log output, the exec should reference the parent file, not the representation file. (I didn't get an explicit answer to whether the plots are being made on the server, so I'll still assuming).

@ericmandel all the files are in check. Only the sizes of the js9*.js files have changed between both branches.

I didn't get an explicit answer to whether the plots are being made on the server, so I'll still assuming

No the plots are not being made at the server yet..

Only the sizes of the js9*.js files have changed between both branches.

Caching problem?

No the plots are not being made at the server yet..

If you are making the plots in the browser, it will use the downloaded blocked file, which might not be what you want.

Caching problem?

Yes, this was it, works now! my mistake and thank you so much.

If you are making the plots in the browser, it will use the downloaded blocked file, which might not be what you want.

So for now, the plots are pre-made and all that is done is to display them, but this will change in the future

So for now, the plots are pre-made and all that is done is to display them, but this will change in the future

Yes, just to be clear -- the plots are associated with regions on the FITS file, but they are not themselves derived from the FITS file. @Mulan-94 precomputes the data needed to render them and stores that server-side, but that's entirely independent of JS9 at this point.

Yes, the server-side analysis should be done with the parent file.

Ah ok, so essentially we've just rebinned the image to 1k x 1k now for display purposes. Well, that's quite good enough for now. Not sure any of the server-side analysis bits are even applicable to our use case (and some of them give errors), so I would be tempted to ask @ericmandel how to hide that menu. Can we customize menus for a "simplified" user experience?
The ImExam stuff is useful though (3D plot especially!) Slightly annoyingly, I get a "No plots available for the selected region" error whenever I use any of this (although the tools e.g. 3D plot actually work just fine). I'm guessing @Mulan-94 this is your message, thrown when the region doesn't have an associated LoS plot? I think in the callback, you need to distinguish somehow the LoS-linked regions you've created, and any user-defined regions.

the plots are pre-made and all that is done is to display them

Ah, I see. That makes me more confident that you should be loading as small a rep file as you can. And if/when you start doing analysis on the server side, the parentFile property will ensure that you do the analysis on the original.
@Mulan-94 totally independent question: when you cloned/pulled the new code, did you get warnings about conflicting filenames in the node_modules/ws directory? If so, I think I tripped over a Mac problem with git.

Not sure any of the server-side analysis bits are even applicable to our use case

If you remove the js9Analysis-fits.json and js9Analysis-funtools.json from the analysys-plugins directory in your installed location, those tasks will not be shown. I don't quite know how to make that configurable during the build process and I got tired/lazy trying to think about it.
Also, yes, you can easily make your own customized menubar. See:
file:///Users/eric/js9/demos/js9menustyles.html

thrown when the region doesn't have an associated LoS plot? I think in the callback, you need to distinguish somehow the LoS-linked regions you've created, and any user-defined regions.

LOS regions can have a second "los" tag ...
tags: ["7", "los"]

btw, if you have specified "selectable" and "removeable" elsewhere, you might want to specify tags in the comments:
circle(950, 1406, 3)  # LOS, 7

This is how DS9 does it, so you get the benefit of being able to check your regions in DS9 too ... if you use that program.

did you get warnings about conflicting filenames in the node_modules/ws directory?

@ericmandel Nope, I didn't get any warnings

This is your message, thrown when the region doesn't have an associated LoS plot

@o-smirnov Yes, that's me, I'll change it.

OK, thanks, I see name conflicts on Linux but not on Mac ... so I bet you're on a Linux box ... definitely a problem with the Mac's case insensitive file system tripping over itself. Yikes.

Mac's case insensitive file system

How anyone ever thought that would be a good idea, boggles the mind...

yeah that definitely comes under the "seemed like a good idea at the time" heading ...

Ah ok, so essentially we've just rebinned the image to 1k x 1k now for display purposes. Well, that's quite good enough for now.

Yes, and at the risk of belaboring the obvious ... if you generate your region coordinates using an image-independent coord system like wcs or physical (the latter assuming you've rebinned using an LTM/LTV-aware program or have added those keywords yourself), you won't have to regenerate the regions if/when you change the bin value.


Close SystemConsumer properly

Changes
KafkaCheckpointManager is a reused class. On reuse, the SystemConsumer can be left unclosed, and a memory leak.
This is because SystemConsumer is started on each start, but closed when

taskNamesToCheckpoints == null and stopConsumerAfterFirstRead == true, or
stopConsumerAfterFirstRead == false

On the second run, taskNamesToCheckpoints != null, and SystemConsumer is never closed.
There are 2 fixes.

Adding a patch to close SystemConsumer properly
Setting taskNamesToCheckpoints back to null on stop()

We are choosing solution 1., since the stopConsumerAfterFirstRead  option expects only 1 read per task(?).
Issue
SAMZA-2785
Calling start() and stop() multiple times on the same KafkaCheckpointManager, while stopConsumerAfterFirstRead == true, causes the SystemConsumer left unclosed. The unclosed SystemConsumer can cause memory leaks in some implementations.
Evidence:
In production logs, SystemConsumer was started 1741 times, but only closed 14 times.
[katxxxx@xxxxxx xxxx]$ grep "Starting the checkpoint SystemConsumer from oldest offset" xxxxxx.log|wc -l
1741
[katxxxxx@xxxxxx xxxx]$ grep "Stopping system consumer" xxxxxxxxxx.log |wc -l
14

We also have a heap dump of KafkaSystemConsumer taking up 8Gbs of memory.

I don't think there is any problem with the existing code. For active containers, the expected behavior is to keep the KafkaCheckpointManager started until the entire container is shutdown which would trigger stop.
On the other hand, for standby containers, there is need to only read checkpoint once and hence closes right after.
I'd trace it back to see if there is any violation in how this flag is set and assumptions that this flag is built on.

I don't think there is any problem with the existing code. For active containers, the expected behavior is to keep the KafkaCheckpointManager started until the entire container is shutdown which would trigger stop.

This PR doesn't change when KafkaCheckpointManager is shutdown. The PR is trying to address that when KafkaCheckpointManager is shutdown, SystemConsumer is left open.

Somehow the KafkaCheckpointManager is started/stopped multiple times in standalone mode.

I don't think there is any problem with the existing code. For active containers, the expected behavior is to keep the KafkaCheckpointManager started until the entire container is shutdown which would trigger stop.

This PR doesn't change when KafkaCheckpointManager is shutdown. The PR is trying to address that when KafkaCheckpointManager is shutdown, SystemConsumer is left open.

I meant SystemConsumer shutdown.
For standalone, the containers are recreated on every rebalance. It is possible that the previous attempts to shutdown the container failed and perhaps, that is being ignored in the application

Then in this case, new SystemConsumers shouldn't be created on KafkaCheckpointManager.start().
Observing the logs in another way, new SystemConsumers are started, but never used to readCheckpoints. They are also never closed, and we see them accumulating in the heap.
This opens a 3rd solution.
  override def start(): Unit = {
     ...
     if(!systemConsumerStarted) {
         systemConsumer.start()
         systemConsumerStarted=true
     }

The idempotent protection line for KafkaSystemConsumer is never triggered in my logs, while there are 168 successful starts and 3 stops.
$grep "Attempting to start the consumer for the second" xxxxx.log.2023-06-21 |wc -l
       0
$grep ": Consumer started" seas-cloud-consumer.log.2023-06-21|wc -l
     168
$grep "Stopping Samza kafkaConsumer" seas-cloud-consumer.log.2023-06-21|wc -l
       3


Oracle CSA keys

Codecov Report

Merging #202 (e1d9902) into main (c76d1f0) will decrease coverage by 0.16%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #202      +/-   ##
==========================================
- Coverage   20.09%   19.93%   -0.17%
==========================================
  Files          12       12
  Lines        1612     1625      +13
==========================================
  Hits          324      324
- Misses       1257     1270      +13
  Partials       31       31

Impacted Files
Coverage Δ

client/chainlink.go
58.58% <0.00%> (-2.44%)
:arrow_down:

client/chainlink_models.go
0.00% <ø> (ø)

Continue to review full report at Codecov.

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


A3 submission

Please do your table in .md.  It looks like the output of "table.py" is nearly there, but do not include it as an image.


feat: add coupon id in delegated checkout API

https://github.com/raystack/proton/pull/352
DelegatedCheckout API accepts provider_coupon_id as the coupon code that will be applied to the subscription generated by the billing provider, this will be deprecated once coupons are managed by the platform

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 17 (0.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.002%) to 9.742%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

proto/v1beta1/models.pb.validate.go
0
2
0.0%

internal/api/v1beta1/billing_checkout.go
0
3
0.0%

proto/v1beta1/models.pb.go
0
5
0.0%

billing/checkout/service.go
0
7
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.002%

Covered Lines:
9465

Relevant Lines:
97152

💛  - Coveralls


Sequence non-persistent objects in cache

Since the datastore interface is common for persistent and
non-persistent objects we need to provide the same kind of sequencing
and atomicity guarantess to non-persistent data operations as we do for
persistent operations. So added sequencing and atomicity checks in the
data cache layer.
Signed-off-by: Jana Radhakrishnan<EMAIL_ADDRESS>

LGTM


java.lang.Number should be Serializable

Currently it just extends Object without any traits.

Other core classes that lack Serializable:

Boolean
Character
BoxedUnit

This also means that primitive JS values should be considered instances of Serializable for is and asInstanceOf


Add performance module

Is your feature request related to a problem? Please describe.
As of now, we only have https://cientos.tresjs.org/guide/misc/stats-gl.html#statsgl to monitor these metrics:

CPU
GPU

Will be nice to have a module or separate panes with these metrics +

Calls
Triangles
Geometries
Textures
Shaders
Lines
Points
Matrices

Similar to https://github.com/utsuboco/r3f-perf

Describe the solution you'd like
We could provide both:

usePerf composable (it will need the renderer context)
<TresPerf> component to set inside <TresCanvas />

All these values should be available on renderer.value in the TresContext, wonder if it's usable or if we will need to approach it differently.

Cancelled in favor of vue-devtools and nuxt-devtools performance monitor


DRILL-8393: Allow parameters to be passed to headers through SQL in WHERE clause

DRILL-8393: Allow parameters to be passed to headers through SQL in WHERE clause
Description
Allow parameters to be passed to headers through SQL in WHERE clause. Use the params configuration item to control what parameters are allowed in, passing them into the body and header depending on the prefix.
Config:
{ "url": "https://api.sunrise-sunset.org/json", "requireTail": false, "params": ["body.lat", "body.lng", "body.date", "header.header1"], "parameterLocation": "json_body" }
SQL Query:
SELECT * FROM api.sunrise
WHERE `body.lat` = 36.7201600
AND `body.lng` = -4.4203400
AND `body.date` = '2019-10-02'
AND `header.header1` = 'value1';

Post body:
{ "lat": 36.7201600, "lng": -4.4203400, "date": "2019-10-02"}
Headers:
{ "header1": "value1", ……}
Documentation
The params configuration mode and SQL parameter passing mode need to be described in the document.
Testing
The params configuration and SQL in the original unit test have been changed and have passed this part of the unit test.

@cgivre I'm not sure if this change is appropriate. I'd love to hear your opinion.

@LYCJeff
I really like the functionality here, but I am concerned that this is a breaking change and will affect existing Drill users.  Also, it adds effectively new syntax to the SQL queries.

@LYCJeff I really like the functionality here, but I am concerned that this is a breaking change and will affect existing Drill users. Also, it adds effectively new syntax to the SQL queries.

@cgivre At this point, I can pass the unprefixed parameters in their place by default, the way they were. This minimizes the impact on existing users, except in the following cases. For example, the argument that the user passed into the request body was called header.xxx, but now needs to be rewritten as body.header.xxx, otherwise the argument will be passed into the request header.
In addition, a problem that had been fixed would reappear. The argument that is passed to the url path is also passed to the end of the url, which has been clearly distinguished since I changed it.
Let me know if you think this is more friendly to existing users, then I'll move in this direction.

Two ideas

Since we won't backport this PR and it will only go out in the next major release, some breakage inside a plugin is probably something that can be swallowed.
If it is still desired to preserve the ability to use the existing syntax in Drill 1.22 and beyond then a storage config option like "useLegacyRequestParmSyntax": true could be added for users who want it.

Two ideas

Since we won't backport this PR and it will only go out in the next major release, some breakage inside a plugin is probably something that can be swallowed.
If it is still desired to preserve the ability to use the existing syntax in Drill 1.22 and beyond then a storage config option like "useLegacyRequestParmSyntax": true could be added for users who want it.

@jnturton @cgivre That's a good idea without confusing old and new syntax, although it requires existing users to make small additions to the configuration. If it is acceptable to you, I will take some time to add a configuration item in the near future.

@LYCJeff Thanks for making these changes.  I have a few questions:

Are you certain that these filters are in fact being pushed down as intended?
I'm really concerned about what would happen if a user aliased a data source as header or tail.

IE:
SELECT ...
FROM api.foo
INNER JOIN dfs.`tail.csv` AS tail
ON tail.id = foo.id
WHERE tail.name = 'something'

Do we know how this would be interpreted?

@LYCJeff Thanks for making these changes. I have a few questions:

Are you certain that these filters are in fact being pushed down as intended?
I'm really concerned about what would happen if a user aliased a data source as header or tail.

IE:
SELECT ...
FROM api.foo
INNER JOIN dfs.`tail.csv` AS tail
ON tail.id = foo.id
WHERE tail.name = 'something'

Do we know how this would be interpreted?

Well, we actually need to recognize header.xxx as a whole parameter name, so we need to use back quotes. Only then can it be pushed normally, so these prefixes are not confused with data source aliases.
If the name in your example above is an argument to the foo api, it should be written as follows.
SELECT ...
FROM api.foo
INNER JOIN dfs.`tail.csv` AS tail
ON tail.id=foo.id
WHERE `tail.name` = 'something'

@LYCJeff
Thank you for submitting this and I'm sorry the review is taking so long.  This is a potentially very breaking change and that's why I've had to give this so much thought.  I've also been quite busy.  Ok...
Let's get this merged.
Here are my final requests:

Please rebase on current master
Can we make the default behavior what Drill currently does and change the boolean parameter to something like enablePostHeadersInWhere or something that uses the word enable?
Make the default behavior to use the current implementation.

Once that's done, I'm good with merging.

Ok, This is looking good. Can you please add a few unit tests, or simply revert a few where the enhanced mode is set to false? Once that's done we're good to go.

I got a COVID. I'll fix it after I recover.

@cgivre Is there anything else I should do for this PR?

@LYCJeff Could you please rebase on current master.  Other than that, LGTM +1.  Sorry this took so long.

@LYCJeff Could you please rebase on current master. Other than that, LGTM +1.
Sorry this took so long. Thank you very much for this contribution!

@cgivre I have updated, thanks for your review.


Help Needed - Decorations

I didn't even think about decorations, but who wants to go to a party that isn't well decorated.... NO ONE, that's who.
Please help me think up decorations for this party. It can be anything from laser lights, to fog machines, to slip-and-slides. Be creative, but I have no clue!
Contribute:

please add your contribution to the root directory of the repo
the file should be called DECORATIONS.md
include images of the objects!
Gif's are encouraged!

Hi Joey! We can contribute some info on decorations, if you'd like!

Hi @KellySchultzUBC  !! Thanks so much for contacting me - I will keep my eye out for a pull request.
🌈


Move "use strict" to apply to the entire file.

Have strict mode apply to all the polyfills, not just a few.

Thanks


/usr/local/bin/brew: line 91: /usr/bin/env: Argument list too long

When I run brew command,it Error“/usr/local/bin/brew: line 91: /usr/bin/env: Argument list too long”
Ex:
lvfeijundeMacBook-Pro:~ lvfeijun$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
==> This script will install:
/usr/local/bin/brew
/usr/local/share/doc/homebrew
/usr/local/share/man/man1/brew.1
/usr/local/share/zsh/site-functions/_brew
/usr/local/etc/bash_completion.d/brew
/usr/local/Homebrew
Press RETURN to continue or any other key to abort
==> Downloading and installing Homebrew...
HEAD 现在位于 203980ac5 Merge pull request #6309 from Homebrew/dependabot/bundler/docs/html-pipeline-2.11.1
/usr/local/bin/brew: line 91: /usr/bin/env: Argument list too long
/usr/local/bin/brew: line 91: /usr/bin/env: Undefined error: 0
Failed during: /usr/local/bin/brew update --force
lvfeijundeMacBook-Pro:~ lvfeijun$ /usr/local/bin/brew update --force
/usr/local/bin/brew: line 91: /usr/bin/env: Argument list too long
/usr/local/bin/brew: line 91: /usr/bin/env: Undefined error: 0
lvfeijundeMacBook-Pro:~ lvfeijun$ brew list
/usr/local/bin/brew: line 91: /usr/bin/env: Argument list too long
/usr/local/bin/brew: line 91: /usr/bin/env: Undefined error: 0
lvfeijundeMacBook-Pro:~ lvfeijun$ brew list
/usr/local/bin/brew: line 91: /usr/bin/env: Argument list too long
/usr/local/bin/brew: line 91: /usr/bin/env: Undefined error: 0

@280482431 Don't recreate duplicate issues. Instead fill out the issue template (https://github.com/Homebrew/brew/issues/new/choose) in this issue.


gca model missing keys

Hello, thank you very much for the framework you provided. When I used the GCA network training in matting, missing keys in source state_dict appeared. The weight of this backbone model is model_best_resnet34_en_nomixup.pth, Could you please give me a look at what might be the cause? Thank you very much！

Please provide the full error log.
If the keys are fc, then it is expected.

@innerlee  missing keys:
`size mismatch for conv1.conv.weight_orig: copying a param with shape torch.Size([32, 6, 3, 3]) from checkpoint, the shape in current model is torch.Size([32, 4, 3, 3]).
size mismatch for conv1.conv.weight_v: copying a param with shape torch.Size([54]) from checkpoint, the shape in current model is torch.Size([36]).
unexpected key in source state_dict: layer_bottleneck.0.conv1.module.weight_u, layer_bottleneck.0.conv1.module.weight_v, layer_bottleneck.0.conv1.module.weight_bar, layer_bottleneck.0.bn1.weight, layer_bottleneck.0.bn1.bias, layer_bottleneck.0.bn1.running_mean, layer_bottleneck.0.bn1.running_var, layer_bottleneck.0.bn1.num_batches_tracked, layer_bottleneck.0.conv2.module.weight_u, layer_bottleneck.0.conv2.module.weight_v, layer_bottleneck.0.conv2.module.weight_bar, layer_bottleneck.0.bn2.weight, layer_bottleneck.0.bn2.bias, layer_bottleneck.0.bn2.running_mean, layer_bottleneck.0.bn2.running_var, layer_bottleneck.0.bn2.num_batches_tracked, layer_bottleneck.0.downsample.1.module.weight_u, layer_bottleneck.0.downsample.1.module.weight_v, layer_bottleneck.0.downsample.1.module.weight_bar, layer_bottleneck.0.downsample.2.weight, layer_bottleneck.0.downsample.2.bias, layer_bottleneck.0.downsample.2.running_mean, layer_bottleneck.0.downsample.2.running_var, layer_bottleneck.0.downsample.2.num_batches_tracked, layer_bottleneck.1.conv1.module.weight_u, layer_bottleneck.1.conv1.module.weight_v, layer_bottleneck.1.conv1.module.weight_bar, layer_bottleneck.1.bn1.weight, layer_bottleneck.1.bn1.bias, layer_bottleneck.1.bn1.running_mean, layer_bottleneck.1.bn1.running_var, layer_bottleneck.1.bn1.num_batches_tracked, layer_bottleneck.1.conv2.module.weight_u, layer_bottleneck.1.conv2.module.weight_v, layer_bottleneck.1.conv2.module.weight_bar, layer_bottleneck.1.bn2.weight, layer_bottleneck.1.bn2.bias, layer_bottleneck.1.bn2.running_mean, layer_bottleneck.1.bn2.running_var, layer_bottleneck.1.bn2.num_batches_tracked, layer_bottleneck.2.conv1.module.weight_u, layer_bottleneck.2.conv1.module.weight_v, layer_bottleneck.2.conv1.module.weight_bar, layer_bottleneck.2.bn1.weight, layer_bottleneck.2.bn1.bias, layer_bottleneck.2.bn1.running_mean, layer_bottleneck.2.bn1.running_var, layer_bottleneck.2.bn1.num_batches_tracked, layer_bottleneck.2.conv2.module.weight_u, layer_bottleneck.2.conv2.module.weight_v, layer_bottleneck.2.conv2.module.weight_bar, layer_bottleneck.2.bn2.weight, layer_bottleneck.2.bn2.bias, layer_bottleneck.2.bn2.running_mean, layer_bottleneck.2.bn2.running_var, layer_bottleneck.2.bn2.num_batches_tracked, fc.weight, fc.bias, layer3.4.conv1.conv.weight_u, layer3.4.conv1.conv.weight_v, layer3.4.conv1.conv.weight_orig, layer3.4.conv1.bn.weight, layer3.4.conv1.bn.bias, layer3.4.conv1.bn.running_mean, layer3.4.conv1.bn.running_var, layer3.4.conv1.bn.num_batches_tracked, layer3.4.conv2.conv.weight_u, layer3.4.conv2.conv.weight_v, layer3.4.conv2.conv.weight_orig, layer3.4.conv2.bn.weight, layer3.4.conv2.bn.bias, layer3.4.conv2.bn.running_mean, layer3.4.conv2.bn.running_var, layer3.4.conv2.bn.num_batches_tracked, layer3.5.conv1.conv.weight_u, layer3.5.conv1.conv.weight_v, layer3.5.conv1.conv.weight_orig, layer3.5.conv1.bn.weight, layer3.5.conv1.bn.bias, layer3.5.conv1.bn.running_mean, layer3.5.conv1.bn.running_var, layer3.5.conv1.bn.num_batches_tracked, layer3.5.conv2.conv.weight_u, layer3.5.conv2.conv.weight_v, layer3.5.conv2.conv.weight_orig, layer3.5.conv2.bn.weight, layer3.5.conv2.bn.bias, layer3.5.conv2.bn.running_mean, layer3.5.conv2.bn.running_var, layer3.5.conv2.bn.num_batches_tracked
missing keys in source state_dict: layer4.0.conv1.conv.weight_orig, layer4.0.conv1.conv.weight, layer4.0.conv1.conv.weight_u, layer4.0.conv1.conv.weight_orig, layer4.0.conv1.conv.weight_u, layer4.0.conv1.conv.weight_v, layer4.0.conv1.bn.weight, layer4.0.conv1.bn.bias, layer4.0.conv1.bn.running_mean, layer4.0.conv1.bn.running_var, layer4.0.conv2.conv.weight_orig, layer4.0.conv2.conv.weight, layer4.0.conv2.conv.weight_u, layer4.0.conv2.conv.weight_orig, layer4.0.conv2.conv.weight_u, layer4.0.conv2.conv.weight_v, layer4.0.conv2.bn.weight, layer4.0.conv2.bn.bias, layer4.0.conv2.bn.running_mean, layer4.0.conv2.bn.running_var, layer4.0.interpolation.1.conv.weight_orig, layer4.0.interpolation.1.conv.weight, layer4.0.interpolation.1.conv.weight_u, layer4.0.interpolation.1.conv.weight_orig, layer4.0.interpolation.1.conv.weight_u, layer4.0.interpolation.1.conv.weight_v, layer4.0.interpolation.1.bn.weight, layer4.0.interpolation.1.bn.bias, layer4.0.interpolation.1.bn.running_mean, layer4.0.interpolation.1.bn.running_var, layer4.1.conv1.conv.weight_orig, layer4.1.conv1.conv.weight, layer4.1.conv1.conv.weight_u, layer4.1.conv1.conv.weight_orig, layer4.1.conv1.conv.weight_u, layer4.1.conv1.conv.weight_v, layer4.1.conv1.bn.weight, layer4.1.conv1.bn.bias, layer4.1.conv1.bn.running_mean, layer4.1.conv1.bn.running_var, layer4.1.conv2.conv.weight_orig, layer4.1.conv2.conv.weight, layer4.1.conv2.conv.weight_u, layer4.1.conv2.conv.weight_orig, layer4.1.conv2.conv.weight_u, layer4.1.conv2.conv.weight_v, layer4.1.conv2.bn.weight, layer4.1.conv2.bn.bias, layer4.1.conv2.bn.running_mean, layer4.1.conv2.bn.running_var, shortcut.0.0.conv.weight_orig, shortcut.0.0.conv.weight, shortcut.0.0.conv.weight_u, shortcut.0.0.conv.weight_orig, shortcut.0.0.conv.weight_u, shortcut.0.0.conv.weight_v, shortcut.0.0.bn.weight, shortcut.0.0.bn.bias, shortcut.0.0.bn.running_mean, shortcut.0.0.bn.running_var, shortcut.0.1.conv.weight_orig, shortcut.0.1.conv.weight, shortcut.0.1.conv.weight_u, shortcut.0.1.conv.weight_orig, shortcut.0.1.conv.weight_u, shortcut.0.1.conv.weight_v, shortcut.0.1.bn.weight, shortcut.0.1.bn.bias, shortcut.0.1.bn.running_mean, shortcut.0.1.bn.running_var, shortcut.1.0.conv.weight_orig, shortcut.1.0.conv.weight, shortcut.1.0.conv.weight_u, shortcut.1.0.conv.weight_orig, shortcut.1.0.conv.weight_u, shortcut.1.0.conv.weight_v, shortcut.1.0.bn.weight, shortcut.1.0.bn.bias, shortcut.1.0.bn.running_mean, shortcut.1.0.bn.running_var, shortcut.1.1.conv.weight_orig, shortcut.1.1.conv.weight, shortcut.1.1.conv.weight_u, shortcut.1.1.conv.weight_orig, shortcut.1.1.conv.weight_u, shortcut.1.1.conv.weight_v, shortcut.1.1.bn.weight, shortcut.1.1.bn.bias, shortcut.1.1.bn.running_mean, shortcut.1.1.bn.running_var, shortcut.2.0.conv.weight_orig, shortcut.2.0.conv.weight, shortcut.2.0.conv.weight_u, shortcut.2.0.conv.weight_orig, shortcut.2.0.conv.weight_u, shortcut.2.0.conv.weight_v, shortcut.2.0.bn.weight, shortcut.2.0.bn.bias, shortcut.2.0.bn.running_mean, shortcut.2.0.bn.running_var, shortcut.2.1.conv.weight_orig, shortcut.2.1.conv.weight, shortcut.2.1.conv.weight_u, shortcut.2.1.conv.weight_orig, shortcut.2.1.conv.weight_u, shortcut.2.1.conv.weight_v, shortcut.2.1.bn.weight, shortcut.2.1.bn.bias, shortcut.2.1.bn.running_mean, shortcut.2.1.bn.running_var, shortcut.3.0.conv.weight_orig, shortcut.3.0.conv.weight, shortcut.3.0.conv.weight_u, shortcut.3.0.conv.weight_orig, shortcut.3.0.conv.weight_u, shortcut.3.0.conv.weight_v, shortcut.3.0.bn.weight, shortcut.3.0.bn.bias, shortcut.3.0.bn.running_mean, shortcut.3.0.bn.running_var, shortcut.3.1.conv.weight_orig, shortcut.3.1.conv.weight, shortcut.3.1.conv.weight_u, shortcut.3.1.conv.weight_orig, shortcut.3.1.conv.weight_u, shortcut.3.1.conv.weight_v, shortcut.3.1.bn.weight, shortcut.3.1.bn.bias, shortcut.3.1.bn.running_mean, shortcut.3.1.bn.running_var, shortcut.4.0.conv.weight_orig, shortcut.4.0.conv.weight, shortcut.4.0.conv.weight_u, shortcut.4.0.conv.weight_orig, shortcut.4.0.conv.weight_u, shortcut.4.0.conv.weight_v, shortcut.4.0.bn.weight, shortcut.4.0.bn.bias, shortcut.4.0.bn.running_mean, shortcut.4.0.bn.running_var, shortcut.4.1.conv.weight_orig, shortcut.4.1.conv.weight, shortcut.4.1.conv.weight_u, shortcut.4.1.conv.weight_orig, shortcut.4.1.conv.weight_u, shortcut.4.1.conv.weight_v, shortcut.4.1.bn.weight, shortcut.4.1.bn.bias, shortcut.4.1.bn.running_mean, shortcut.4.1.bn.running_var, guidance_head.0.conv.weight_orig, guidance_head.0.conv.weight, guidance_head.0.conv.weight_u, guidance_head.0.conv.weight_orig, guidance_head.0.conv.weight_u, guidance_head.0.conv.weight_v, guidance_head.0.bn.weight, guidance_head.0.bn.bias, guidance_head.0.bn.running_mean, guidance_head.0.bn.running_var, guidance_head.1.conv.weight_orig, guidance_head.1.conv.weight, guidance_head.1.conv.weight_u, guidance_head.1.conv.weight_orig, guidance_head.1.conv.weight_u, guidance_head.1.conv.weight_v, guidance_head.1.bn.weight, guidance_head.1.bn.bias, guidance_head.1.bn.running_mean, guidance_head.1.bn.running_var, guidance_head.2.conv.weight_orig, guidance_head.2.conv.weight, guidance_head.2.conv.weight_u, guidance_head.2.conv.weight_orig, guidance_head.2.conv.weight_u, guidance_head.2.conv.weight_v, guidance_head.2.bn.weight, guidance_head.2.bn.bias, guidance_head.2.bn.running_mean, guidance_head.2.bn.running_var, gca.guidance_conv.weight, gca.guidance_conv.bias, gca.out_conv.conv.weight, gca.out_conv.bn.weight, gca.out_conv.bn.bias, gca.out_conv.bn.running_mean, gca.out_conv.bn.running_var`

Hi, @15122901359. Where is the pretrained weight model_best_resnet34_en_nomixup.pth from?

I've meet the same problem, and I download the pretrained model 'model_best_resnet34_en_nomixup.pth' from https://github.com/open-mmlab/mmcv/blob/b4bfeb53c5/mmcv/model_zoo/open_mmlab.json

Thank you @Dinghow for your information! I've checked with the pretrained weight provided by the json file. The pretrained weight file is outdated.
We will update the latest pretrained weight as soon as possible. Thank you!

Hi @yuchengtianxia, I am not sure about the exact date, but I guess we will probably update it in the next two weeks.

The pretrained weight is now updated.

Hi @hejm37, Thank you for your work! I trained the GCA network with the updated pretrained weights (https://github.com/open-mmlab/mmcv/blob/b4bfeb53c5/mmcv/model_zoo/open_mmlab.json), but missing keys still appeared. The log shows: WARNING - The model and loaded state dict do not match exactly
size mismatch for layer4.0.conv1.conv.weight_orig: copying a param with shape torch.Size([256, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([512, 256, 3, 3]).
size mismatch for layer4.0.conv1.conv.weight_u: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.conv1.bn.weight: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.conv1.bn.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.conv1.bn.running_mean: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.conv1.bn.running_var: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.conv2.conv.weight_orig: copying a param with shape torch.Size([256, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([512, 512, 3, 3]).
size mismatch for layer4.0.conv2.conv.weight_u: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.conv2.conv.weight_v: copying a param with shape torch.Size([2304]) from checkpoint, the shape in current model is torch.Size([4608]).
size mismatch for layer4.0.conv2.bn.weight: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.conv2.bn.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.conv2.bn.running_mean: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.conv2.bn.running_var: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.interpolation.1.conv.weight_orig: copying a param with shape torch.Size([256, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([512, 256, 1, 1]).
size mismatch for layer4.0.interpolation.1.conv.weight_u: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.interpolation.1.conv.weight_v: copying a param with shape torch.Size([2304]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for layer4.0.interpolation.1.bn.weight: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.interpolation.1.bn.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.interpolation.1.bn.running_mean: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.0.interpolation.1.bn.running_var: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.1.conv1.conv.weight_orig: copying a param with shape torch.Size([256, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([512, 512, 3, 3]).
size mismatch for layer4.1.conv1.conv.weight_u: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.1.conv1.conv.weight_v: copying a param with shape torch.Size([2304]) from checkpoint, the shape in current model is torch.Size([4608]).
size mismatch for layer4.1.conv1.bn.weight: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.1.conv1.bn.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.1.conv1.bn.running_mean: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.1.conv1.bn.running_var: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([512]).
size mismatch for layer4.1.conv2.conv.weight_orig: copying a param with shape torch.Size([512, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([512, 512, 3, 3]).
size mismatch for layer4.1.conv2.conv.weight_v: copying a param with shape torch.Size([2304]) from checkpoint, the shape in current model is torch.Size([4608]).
size mismatch for shortcut.0.0.conv.weight_orig: copying a param with shape torch.Size([512, 512, 3, 3]) from checkpoint, the shape in current model is torch.Size([32, 6, 3, 3]).
size mismatch for shortcut.0.0.conv.weight_u: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.0.0.conv.weight_v: copying a param with shape torch.Size([4608]) from checkpoint, the shape in current model is torch.Size([54]).
size mismatch for shortcut.0.0.bn.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.0.0.bn.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.0.0.bn.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.0.0.bn.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.0.1.conv.weight_orig: copying a param with shape torch.Size([512, 256, 1, 1]) from checkpoint, the shape in current model is torch.Size([32, 32, 3, 3]).
size mismatch for shortcut.0.1.conv.weight_u: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.0.1.conv.weight_v: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([288]).
size mismatch for shortcut.0.1.bn.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.0.1.bn.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.0.1.bn.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.0.1.bn.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.0.conv.weight_orig: copying a param with shape torch.Size([512, 512, 3, 3]) from checkpoint, the shape in current model is torch.Size([32, 32, 3, 3]).
size mismatch for shortcut.1.0.conv.weight_u: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.0.conv.weight_v: copying a param with shape torch.Size([4608]) from checkpoint, the shape in current model is torch.Size([288]).
size mismatch for shortcut.1.0.bn.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.0.bn.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.0.bn.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.0.bn.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.1.conv.weight_orig: copying a param with shape torch.Size([512, 512, 3, 3]) from checkpoint, the shape in current model is torch.Size([32, 32, 3, 3]).
size mismatch for shortcut.1.1.conv.weight_u: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.1.conv.weight_v: copying a param with shape torch.Size([4608]) from checkpoint, the shape in current model is torch.Size([288]).
size mismatch for shortcut.1.1.bn.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.1.bn.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.1.bn.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.1.1.bn.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([32]).
size mismatch for shortcut.2.0.conv.weight_orig: copying a param with shape torch.Size([512, 512, 3, 3]) from checkpoint, the shape in current model is torch.Size([64, 64, 3, 3]).
size mismatch for shortcut.2.0.conv.weight_u: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for shortcut.2.0.conv.weight_v: copying a param with shape torch.Size([4608]) from checkpoint, the shape in current model is torch.Size([576]).
size mismatch for shortcut.2.0.bn.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for shortcut.2.0.bn.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for shortcut.2.0.bn.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for shortcut.2.0.bn.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for shortcut.2.1.conv.weight_orig: copying a param with shape torch.Size([512, 512, 3, 3]) from checkpoint, the shape in current model is torch.Size([64, 64, 3, 3]).
size mismatch for shortcut.2.1.conv.weight_u: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for shortcut.2.1.conv.weight_v: copying a param with shape torch.Size([4608]) from checkpoint, the shape in current model is torch.Size([576]).
size mismatch for shortcut.2.1.bn.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for shortcut.2.1.bn.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for shortcut.2.1.bn.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
size mismatch for shortcut.2.1.bn.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([64]).
unexpected key in source state_dict: fc.weight, fc.bias
missing keys in source state_dict: shortcut.3.0.conv.weight_orig, shortcut.3.0.conv.weight, shortcut.3.0.conv.weight_u, shortcut.3.0.conv.weight_orig, shortcut.3.0.conv.weight_u, shortcut.3.0.conv.weight_v, shortcut.3.0.bn.weight, shortcut.3.0.bn.bias, shortcut.3.0.bn.running_mean, shortcut.3.0.bn.running_var, shortcut.3.1.conv.weight_orig, shortcut.3.1.conv.weight, shortcut.3.1.conv.weight_u, shortcut.3.1.conv.weight_orig, shortcut.3.1.conv.weight_u, shortcut.3.1.conv.weight_v, shortcut.3.1.bn.weight, shortcut.3.1.bn.bias, shortcut.3.1.bn.running_mean, shortcut.3.1.bn.running_var, shortcut.4.0.conv.weight_orig, shortcut.4.0.conv.weight, shortcut.4.0.conv.weight_u, shortcut.4.0.conv.weight_orig, shortcut.4.0.conv.weight_u, shortcut.4.0.conv.weight_v, shortcut.4.0.bn.weight, shortcut.4.0.bn.bias, shortcut.4.0.bn.running_mean, shortcut.4.0.bn.running_var, shortcut.4.1.conv.weight_orig, shortcut.4.1.conv.weight, shortcut.4.1.conv.weight_u, shortcut.4.1.conv.weight_orig, shortcut.4.1.conv.weight_u, shortcut.4.1.conv.weight_v, shortcut.4.1.bn.weight, shortcut.4.1.bn.bias, shortcut.4.1.bn.running_mean, shortcut.4.1.bn.running_var, guidance_head.0.conv.weight_orig, guidance_head.0.conv.weight, guidance_head.0.conv.weight_u, guidance_head.0.conv.weight_orig, guidance_head.0.conv.weight_u, guidance_head.0.conv.weight_v, guidance_head.0.bn.weight, guidance_head.0.bn.bias, guidance_head.0.bn.running_mean, guidance_head.0.bn.running_var, guidance_head.1.conv.weight_orig, guidance_head.1.conv.weight, guidance_head.1.conv.weight_u, guidance_head.1.conv.weight_orig, guidance_head.1.conv.weight_u, guidance_head.1.conv.weight_v, guidance_head.1.bn.weight, guidance_head.1.bn.bias, guidance_head.1.bn.running_mean, guidance_head.1.bn.running_var, guidance_head.2.conv.weight_orig, guidance_head.2.conv.weight, guidance_head.2.conv.weight_u, guidance_head.2.conv.weight_orig, guidance_head.2.conv.weight_u, guidance_head.2.conv.weight_v, guidance_head.2.bn.weight, guidance_head.2.bn.bias, guidance_head.2.bn.running_mean, guidance_head.2.bn.running_var, gca.guidance_conv.weight, gca.guidance_conv.bias, gca.out_conv.conv.weight, gca.out_conv.bn.weight, gca.out_conv.bn.bias, gca.out_conv.bn.running_mean, gca.out_conv.bn.running_var

It's normal to have those missing keys since only partial weights of the encoder are from pretrained weights.

@hejm37 I only changed "bg_dir = './data/coco/train2017'" in the default config to "bg_dir = './data/coco/train2014'", and other settings remain unchanged. I think the bg_dir setting has nothing to do with the model structure, but the error of size mismatches still exist.

Hi @hejm37, I also met the problem of mismatch between the model and the pre-trained weight, The log shows: "The model and loaded state dict do not match exactly". The pre-trained weight did not work.

@LeoXing1996
Please check this issue.

Hey @yuchengtianxia , can you provide the URL of the checkpoint you used?

Closing due to inactivity, please reopen if there are any further problems.


Server crushes when file name is not provided

Please specify what steps you have taken to achieve this effect.


epoch option to log_model using WandbLogger

🚀 Feature
WandbLogger should have an optional parameter, log_model_every_k_epochs, in which case the model is logged periodically.
Motivation
WandbLogger appears only to log the model on finalize. This is different than the default ptl behavior, and also means that model logging happens unpredictably.
Pitch
If Google Colab terminates your training, WandbLogger doesn't save your model.
If you cancel training and start editing your Jupyter notebook, WandbLogger doesn't save your model.
There is a high potential for human error in forgetting to manually call WandbLogger.finalize()
Alternatives
I believe one can manually call WandbLogger.finalize() if they are monitoring the job. I don't know if this means that the logger cannot be reused or the training job continued.
Also, this workaround doesn't help in the setting where Colab shuts down an instance without warning.

n00b question: Would it be easier to extend the ModelCheckpoint callback for specific WandB functionality?


Redundant steer to "visit review" when duplicate module review is entered

Journey:

Already reviewed ITP1
Go to Courses and select ITP1 again (and fill in other boxes with valid input)
Hit Submit
My original review is presented to me (not the new review), however this page also has "You have already reviewed this course. Would you like to edit it? Visit review" link on it which is redundant, as I am already there.

Suggest after hitting Submit, the new review remains on the page, in case the user has selected the wrong module by accident. Then their text isn't lost.

Thanks for the suggestion Ruth. I agree with your suggestion. In addition I think we should flash a message indicating they have already reviewed the course and add a link that takes them to the edit review.
For some more context, the visit review link is hardcoded into the flash message in the editreview.html template. It will always show a link to the review regardless of the message. This was originally implemented so that you would have a link after editing so that you could see the review - however, it's not always that relevant (such as this situation). Ideally it should probably be part of the message sent from the server but it wasn't clear to me how to ensure it rendered as link instead of text.


iPhone 6, iOS 10.3.3 - Text issues

The info text about being exposed is overlapping and is hard to read. This problem is present only in Hebrew and English, Russian and Arabic seems to be fine.
(Also, the fifth language seems to be missing encoding and therefore shows question marks)
iPhone 6, iOS 10.3.3, app ver. 1.0.20 (updated on 23/3/2020)

Closed by #93 . @vikidish can you please verify it works for you?


Reset signals after Screen wrapper/close

Hi Peter,
I've been using asciimatics for a while now (thank you), and I've finally tracked down a bug involving terminal resize AFTER asciimatics is no longer being used. It looks like a signal handler for terminal resize is set, which disables and re-enables curses, however this signal handler continues to persist for the duration of the python process, causing curses to be enabled and scrambling text whenever the terminal is resized, even after asciimatics wrapper has closed and called endwin is called for curses.
The line in question is:
asciimatics/screen.py:1861:
        signal.signal(signal.SIGWINCH, self._resize_handler)

Perhaps something like signal.signal(signal.SIGWINCH, signal.SIG_DFL) could be in _CursesScreen.close for when restore is True.
I think I may be using asciimatics differently than everyone else (wrapper doesn't last for the entirety of the python process), but perhaps my use-case is valid.
Let me know what you think,
Bryce

Sounds like a good plan to tidy that up properly to me!  Thanks for taking the time to fix up the code.
I've had a quick look and have requested a couple of changes to try to catch all the ways the signal handling could go wrong.

All done!  Thanks for the fix.


No refund-tx if CET was confirmed

fixes https://github.com/itchysats/itchysats/issues/2168
It can happen that upon startup of the application that the refund timelock is already expired, but we publish the CET and not refund.
This is because the CET has priority over refund even if the refund timelock is already expired.
In RefundTimelockExpired we cannot know if the CET was confirmed or not (becuase this is a later state).
We opt for setting refund_tx to None and refund_published to false to ensure we do not wrongly show the refund-tx in the user interface if the CET was confirmed on chain.

I am not super happy about this, but I did not find a better solution for now. Not setting the refund tx in case we have a CET available might have weird side effects.
The projection should be refactored to be more driven by the state on chain. If we have a spend transaction confirmed on chain there is not point in arguing about other events! But this is a bigger changes.

bors r+


Improve to readme for the MEMOTE additions

/format

Codecov Report
Patch coverage: 85.71% and project coverage change: -14.66 :warning:

Comparison is base (c11ca82) 95.05% compared to head (7cea182) 80.40%.

Additional details and impacted files
@@             Coverage Diff             @@
##           master      #71       +/-   ##
===========================================
- Coverage   95.05%   80.40%   -14.66%
===========================================
  Files          16       20        +4
  Lines         607      592       -15
===========================================
- Hits          577      476      -101
- Misses         30      116       +86

Impacted Files
Coverage Δ

src/memote.jl
100.00% <ø> (ø)

src/memote/checks/Energy.jl
0.00% <ø> (-89.48%)
:arrow_down:

src/memote/frontend.jl
71.42% <71.89%> (-10.11%)
:arrow_down:

src/memote/utils.jl
50.00% <85.71%> (-50.00%)
:arrow_down:

src/memote/checks/Reactions.jl
95.83% <95.83%> (ø)

src/memote/checks/Annotation.jl
100.00% <100.00%> (ø)

src/memote/checks/Basic.jl
100.00% <100.00%> (ø)

src/memote/checks/Biomass.jl
100.00% <100.00%> (ø)

src/memote/checks/Consistency.jl
100.00% <100.00%> (ø)

src/memote/checks/GPRAssociation.jl
100.00% <100.00%> (ø)

... and 3 more

... and 2 files with indirect coverage changes

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

/format