Hull issue (for v3)

I have created a block for you to view which shows the error very clearly here:
http://bl.ocks.org/Anupheaus/f79c12c2cec45caa9dfd1e6466663ef2
Basically, the issue is that when you add a new array of points to the hull data, two of the new points seem to affect the hull before the transition is applied.  This only happens if the points being added are to the right of the original point, so if the second point was to the left of the first point, it doesn't happen.

This is not a bug in D3. You are trying to use d3.interpolateString to interpolate two paths with a different structure (a different number of control points). For more about this problem I recommend taking a look at flubber and Noah Veltman’s talk on shape interpolation:
https://github.com/veltman/flubber
https://www.youtube.com/watch?v=PLc1y-gim_0
Please use Stack Overflow tag d3.js to ask for help. Although I make an effort to assist everyone that asks, I am not always available to provide help promptly or directly. Stack Overflow provides a better collaborative forum for self-help: tens of thousands of D3-related questions have already been asked there, and some answered questions may be relevant to you.
If you have a question about D3’s behavior and want to discuss it with other users, also consider the d3-js Google Group or joining the d3-js Slack.
Thank you! 🤗


Transalted the limitrange.md to Japanese

Issue: #47684
What This PR Does
This PR addresses the issue of translating the limitrange.md file from English to Japanese. The original English file is located in the content/en/docs/reference/glossary/limitrange.md path, and this translation provides the Japanese localization for the glossary term "LimitRange."
Why This Is Needed
The Kubernetes documentation aims to support a diverse global community. By translating this glossary term into Japanese, we help Japanese speakers better understand Kubernetes concepts in their native language. This is part of ongoing efforts to improve the accessibility and inclusiveness of Kubernetes documentation.

This translates the English page itself into Japanese, which doesn't align with the requirements of issue https://github.com/kubernetes/website/issues/47684 and is not what we need.
/hold

Thank you for this work, @VinayakPaka and kind support, @dipesh-rawat
As Dipesh mentioned, we do not want to make changes to the English (original) content. I recommend creating a new PR, thanks

This PR has not progressed for about a month, so I would like to close
If necessary, please create another one, thanks
/close


Enhancements to discovery SOLR harvesting

@xuezhaokun @dtarb @rayi113 @jbradberry
Now that real-time discovery harvesting works, we can start thinking about how it should work. I am putting this into a new ticket so that we can close the other one.
Here are some immediate thoughts. First I propose the following easy performance fixes:

don't index things at all that are neither public nor discoverable.
add a resource to the index only when it becomes discoverable or public.
delete a resource from the index when it goes from discoverable or public to private.

This will save an enormous amount of processing time. Normally people don't make things public until they're presentable. Thus we can save a lot of time by not indexing things that people aren't finished with.
Also, there are several other fixes that will slightly improve performance and make the code simpler. Notably:

change the signal registration to invoke a pre-delete action rather than a post-delete action.  This will make managing deletes easier by giving us a complete view of what is going to be deleted rather than a partially deleted view like we have now with the delete "in progress" before we get the signal...!

I also think that it is possible to refine our signal registration to only receive updates for resources. I am not absolutely sure how, and this will take a little trial and error.
Note that we should also omit some of the massive logger.debug() postings that we added to understand the signal system, for performance reasons.

If we do the above, I am not sure we even need queueing. The processing will only be slow if someone changes a public resource.

@alvacouch Not sure whether this issue can be covered by [#1187] or you want to do more enhancements for solr harvesting in this issue.

@alvacouch @hyi @dtarb @rayi113 I strongly suggest that Hydroshare does not need real-time updates of the search engine.  A queuing system where writes to Solr happen every 5 or 10 minutes would be, I think, reasonable and would cut down on the churn of writes to the Solr server.
That said, points 1 through 3 seem to be reasonable and correct criteria.

From a user perspective I agree with @jbradberry.  Resources do not need to be immediately discoverable.   I do not have a basis for opining on whether it is more efficient to just add to Solr when the public action is taken, or have a queue do writes every 10 min.  That is an implementation detail I am happy to leave to the Discovery coders.

@alvacouch @xuezhaokun  Should this be closed?

This has been addressed. (Users absolutely demanded real-time updates.)


can't see haver shadow in darkmode

TuSimple/naive-ui version (版本)
2.16.7
Vue version (Vue 版本)
3.2.8
Browser and its version (浏览器及其版本)
Chrome
System and its version (系统及其版本)
Windows
Node version (Node 版本)
Reappearance link (重现链接)
https://codesandbox.io/api/v1/sandboxes/define
Reappearance steps (重现步骤)
when the background is #000
Can't see haver shadow! Maybe the shadow need to be bright insted of the grey one in light mode
Expected results (期望的结果)
see the haver shadow in darkmode
Actual results (实际的结果)
can't see haver shadow because of the color is still darkgrey but not light grey
Remarks (补充说明)

The reappearance link can not opened.

Update the reproduction link and I'll reopen the issue.

Update the reproduction link and I'll reopen the issue.

update the link,please check ,click the button to the darkmode

Update the reproduction link and I'll reopen the issue.

update the link,please check ,click the button to the darkmode

It's too dark to make the shadow visible.

You can apply some extra CSS in dark theme. It's impossible to make every cases work well.

You can apply some extra CSS in dark theme. It's impossible to make every cases work well.

maybe box-shawdow need to be rgba(255,255,255,0.06) will display better in darkmode instead of the dark

In light mode, we use shadows to express elevation. The higher surface gets, the wider a shadow it casts. The same approach wouldn’t work in a dark theme — it’s hard to see a shadow against a dark background. It’s better to illuminate the surface of each level. The higher a surface’s elevation, the lighter that surface becomes.

from: https://uxplanet.org/8-tips-for-dark-theme-design-8dfc2f

You can apply some extra CSS in dark theme. It's impossible to make every cases work well.

maybe box-shawdow need to be rgba(255,255,255,0.06) will display better in darkmode instead of the dark

In light mode, we use shadows to express elevation. The higher surface gets, the wider a shadow it casts. The same approach wouldn’t work in a dark theme — it’s hard to see a shadow against a dark background. It’s better to illuminate the surface of each level. The higher a surface’s elevation, the lighter that surface becomes.

from: https://uxplanet.org/8-tips-for-dark-theme-design-8dfc2f

I know illuminate the surface is a way to show elevation. However I haven't find any examples of transition from a elevation level to another elevation level in dark mode.

a elevation level

thx for your explain, i will try a lighter background to make the shadow visible


Confusing usage message for collection options

The following test app:
@CommandLine.Command(name = "app")
public class App {

    @CommandLine.Option(names = "-n", paramLabel = "NAME", description = "list of names", type = String.class/*, arity = "1..*"*/)
    List<String> names = new LinkedList<>();

    public static void main(String[] args) {
        App app = new App();
        CommandLine cl = new CommandLine(app);
        cl.usage(System.out);
    }

}

Produces:
Usage: app [-n[=NAME...]]
  -n= =NAME...]               list of names

It would be better something like this:
Usage: app [-n[=NAME...]]
  -n= [NAME [NAME...]]               list of names

Interestingly uncommenting the arity specification produces a better usage:
Usage: app [-n=NAME [NAME...]]
  -n= NAME [NAME...]          list of names

Oops. This is a bug. Thanks for letting me know!

Fixed in master, please confirm.
After this change, the usage message will be as below because of the changes made for #192:
Usage: app [-n=NAME]...
  -n= NAME                    list of names

The #192 change means that multi-value options (array, list, map fields) no longer greedily consume arguments. They just consume 1 arg by default. If the user wants to specify multiple values they need to specify the option multiple times:
app -n AAA -n BBB -n CCC

With arity uncommented (meaning that every -n option can be followed by one or more NAMEs), the usage looks like this:
Usage: app [-n=NAME...]...
  -n= NAME...                 list of names

I won't have a chance to try your latest improvements right now, sorry. I will try my best next week.
However I like the change made for #192, an option consuming multiple arguments is confusing and should be avoided in favor of specifying that option more than once


Address feedback on initial a11y changes

Description
After the big sweep of a11y tasks over the last couple of weeks, @shinechaudhuri and @mkewins provided some great feedback (internal only) on these updates from a design / product perspective.
This task addresses that feedback.
Acceptance Criteria

[x] remove gray "total count" boxes for Collisions and Studies on View Data
[x] reduce size of <h2> headings to save space: View Data, Track Requests, View Request, Request Study
[x] change "Details" to "Request Details" in View Request
[x] add left margin spacing between action buttons and title in View Request header
[ ] revamp top navigation:

[ ] move side navigational elements into top bar
[ ] add Back button to top bar
[x] use border instead of box-shadow
[ ] get rid of title?

[ ] from MOVE-130: rethink headers on non-map pages

Additional Notes
Add any other context or screenshots about the feature request here.

Marking closed for now - we can open more specific tasks on the navigational pieces as needed, but if we're planning to keep both top and side anyways we can likely make do with what we have for next release.


[android]Unable to resolve module image!android_search_white when run Examples/Movies?

from #3545  When I put android_search_white.png in the same folder as  JS files, and modify the searchBar.android.js as below
 source={require('./android_search_white.png')}

the Movie app is running OK.
Why  require('image!android_search_white') not work ?
I have checked the png files path, they are right in Examples/Movies/android/app/src/main/res/drawable-hdpi  .

you can try to create the folder "drawable"

@jinhui185190197  I have tried, not work also.

can someone share the sample project for loading a static image on android please.

@wunnath http://facebook.github.io/react-native/docs/images.html#content

@yanggeorge You need to use <Image source={{ uri: "android_search_white.png" }} />


Make shelfmark a required field on source create and edit forms

This was causing a TypeError on the source create and edit forms. Also adds the fix to the admin source create form. Fixes #1604

Shelfmark should also be marked as required in the Source model. Also, holding_institution needs to be marked as required in both the editing form and the model.

Shelfmark should also be marked as required in the Source model. Also, holding_institution needs to be marked as required in both the editing form and the model.

Was the fact that these weren't previously required because null needed to be allowed while we transitioned the records? But the intention was that they really shouldn't allow null after that?

Was the fact that these weren't previously required because null needed to be allowed while we transitioned the records?

Yep.

Great... I think it makes sense to make those changes, and then when we update production we just won't apply this migration, then run migrate_records, and then apply this last migration.
@lucasmarchd01 Do you want to add those changes here or we can create another issue?

There's a migration script that needs to be added, but I can generate that after #1615 is merged.


extract_base_hudfiles.bat

You might want to include the HLExtract folder with the .exe and .dll files in the hud for the extraction to work.
HLExtract.zip

I had the directory there, but my global gitignore was ignoring .exe and .dll's so it never wanted to add the directory.  Thanks for the heads up, I fixed it.


hugo: 0.92.2 -> 0.93.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/gohugoio/hugo/releases.
meta.description for hugo is: "A fast and modern static website engine"
meta.homepage for hugo is: "https://gohugo.io"
meta.changelog for hugo is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
Warning: no invocation of /nix/store/sjgrirfb1brr9srsp020l9qxqks9qkks-hugo-0.93.0/bin/hugo had a zero exit code or showed the expected version
0 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 0.93.0 in filename of file in /nix/store/sjgrirfb1brr9srsp020l9qxqks9qkks-hugo-0.93.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
hugo

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/sjgrirfb1brr9srsp020l9qxqks9qkks-hugo-0.93.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A hugo https://github.com/r-ryantm/nixpkgs/archive/4fa71e55f9a3abc6657adf41f4868b0a629ec762.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/sjgrirfb1brr9srsp020l9qxqks9qkks-hugo-0.93.0
ls -la /nix/store/sjgrirfb1brr9srsp020l9qxqks9qkks-hugo-0.93.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

hugo

Maintainer pings
cc @schneefux @Br1ght0ne @Frostman @kalbasit for testing.

Closing in favor of  #164538


Update PartitionHandler partition properties during initialization

The PartitionHandler has per-binding partition properties derived from the producer properties for the binding

These partition properties (especially PartitionKeyExtractorStrategy and PartitionSelectorStrategy)  need not be initialized when the messages are processed; instead they can be set during the PartitionHandler instantiation

Add tests

This resolves #772

Squashed and merged as https://github.com/spring-cloud/spring-cloud-stream/commit/2df9f9b4ee30dff6aad7773d8d033111c1a5348d
Cherry-picked as https://github.com/spring-cloud/spring-cloud-stream/commit/80411f0b191a75ad398d6834f4e20ec755803584


Simplify Logging Code

You've currently got e.g.
https://github.com/OpenLightingProject/rp2040-dongle/blob/08e6e144c32b5bf002fd0e936cf510dbeb2a6162/src/jaruleproto.c#L15
In OLA we use __FILE__ too, but we also setup a macro to centralise and tidy most of the back-end commands (although I guess the latter might be a bit harder if it's all in a printf):
https://github.com/OpenLightingProject/ola/blob/ea3a18a925f123c8771ebc6c60327678e99ddcf2/include/ola/Logging.h#L59-L60

Indeed, fully agree. That is meant to be a macro eventually. For the moment, it's just written to fulfil the needs.
I did try __LINE__, however it contains the full file path and that was a bit long for me. I saw some functions online that return only he filename but I didn't yet bother to integrate them.

I did try __LINE__, however it contains the full file path and that was a bit long for me. I saw some functions online that return only he filename but I didn't yet bother to integrate them.

I assume you mean __FILE__? That's interesting, in OLA we just get the relative path (say src/jaruleproto.c).

Indeed, I meant __FILE__. Maybe it depends on the build system used? It could be that OLA's GNU Make-based build system calls the compiler with relative paths while the CMake-based build system for Pico-projects calls the compiler with absolute paths?

I played around a little with the logging code. Actually, rather for checking if C++ can be used on the RP2040. Result: Working, but some things (such as iterators) will lead to compile-time errors such as https://github.com/purduesigbots/pros/issues/134
Current status at https://github.com/OpenLightingProject/rp2040-dongle/tree/kripton-cppTest. Can be used as a base but I might rewrite that in plain C. Will see ;)


Debug messages yield TypeErrors

Several unit tests failed with the following stack trace during the overnight builds. Why these unit tests went down this path is still a mystery. But they did, which means if a user sets VERBOSE to True they would see the same exception.
Either change these debug prints to handle the booleans, or remove them. And if they're going to get updated, consider changing them to logging statements instead of prints.
Traceback (most recent call last):
  File "/home/runner/work/pySBOL2/pySBOL2/test/test_identified.py", line 110, in test_name
    cd = d.componentDefinitions['http://examples.org/ComponentDefinition/AmeR/1']
  File "/home/runner/work/pySBOL2/pySBOL2/sbol2/property.py", line 641, in __getitem__
    return self.get_uri(rdflib.URIRef(id))
  File "/home/runner/work/pySBOL2/pySBOL2/sbol2/property.py", line 669, in get_uri
    print('SBOL compliant URIs are set to ' +
TypeError: can only concatenate str (not "bool") to str

The build jobs succeeded when rerun so it remains a mystery how VERBOSE was set to True to trigger the exception in this issue. There were other exceptions relating to online services that were not available, so that might have triggered it.
If the online services (validator, SynBioHub) are down regularly for overnight builds we might want to change the build schedule to a different time. We could work with the owners of those services to understand what their maintenance schedule is to understand what time windows should be avoided.


Support variadic templates from STL

This commit adds the support for variadic templates as long as they are coming from the standard library. It was achieved by supporting the Pack type of CXTemplateArgumentKind.
This commit also fixed a bug of getting the full name of a CppElement so it does not throw a lot of unexpected exceptions.

The failed build is caused by a version mismatch between MSVC and Clang. 😞 The build agent apparently is using a fairly new version of MSVC (2022, 14.37.32822) that needs a Clang version higher than 16. The Clang version that is used by CppAST is 15.0.2.

[ ] Update the commit message to say we are using .NET 6.0


[FRONTEND] Added support for IR files cached in different directories.

This is mainly targeted to cache that is stored on the blob storage, each IR ends up in a different directory, and the only way to keep track of the cache paths is by keeping track of each one and passing it to the CompiledKernel to construct the asm dict.

LG, can you add a short description on what this solves? (I have a guess but I'm actually not sure)

Done

LG, can you add a short description on what this solves? (I have a guess but I'm actually not sure)

Done

Thanks! LGTM


Upload from Scratch (URL)

https://github.com/OpenSprites/OpenSprites-next/issues/62#issuecomment-235080852

Should we have an "upload from Scratch URL" option? :shipit:

All ideas belong in an issue. :)
@MegaApuTurkUltra

I feel like having an "upload from scratch url" present at all times could be clutter...
Even so, we could implement this as, like, a button in the Chrome/FF Extension to appear on actual scratch project pages?

Done


Add offset to dialog relative to the center bottom position of the screen

Maybe it would be cool to have an option to pin it to other places (make it relative to them) too? Becaus that would mean more freedom for theplacement of the dialogue box.
I got the idea from the speech bubble that AnidemDex posted inthe Discord server.

Yeah, I was thinking of a selector for docking it to top, left, bottom, right and the offset. But for now I wanted to make a note about making this one since I think it should be simple enough


Added async api methods

Hope this will be of some use...
I've updated the project to use .net 4.5 but if need be I can downgrade it again to .net 4.0.
As you can see at present I've just added another set of Async methods so as not to break backwards comparability - or would you rather release an async only version of the API and call it a nuget v2?

Hi - any feedback on this?

Hey!  Thanks for the PR!  Aync/await is awesome and it's great that the client can be made fully async.  After giving it some thought, I think we should go with the async only version and rev the major version number.

@tekmaven I've removed those sync API's as requested so we're all async'd up!

Thanks!  I have merged your changes and released nuget package 3.0!


Support for GraphSON

https://github.com/tinkerpop/blueprints/wiki/GraphSON-Reader-and-Writer-Library

Already in 3.0 (and maybe 2.2.x)


kubectl-example: 1.0.1 -> 1.1.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/seredot/kubectl-example/releases.
meta.description for kubectl-example is: "kubectl plugin for retrieving resource example YAMLs"
meta.homepage for kubectl-example is: "https://github.com/seredot/kubectl-example"
meta.changelog for kubectl-example is: "https://github.com/seredot/kubectl-example/releases/tag/v1.1.0"
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
/nix/store/h6lmak6r4r0rcg2y0i9hw74mdnzkp71x-kubectl-example-1.1.0/bin/kubectl-example passed the binary check.
1 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 1.1.0 with grep in /nix/store/h6lmak6r4r0rcg2y0i9hw74mdnzkp71x-kubectl-example-1.1.0
found 1.1.0 in filename of file in /nix/store/h6lmak6r4r0rcg2y0i9hw74mdnzkp71x-kubectl-example-1.1.0

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
docbookrx
kubectl-example

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/h6lmak6r4r0rcg2y0i9hw74mdnzkp71x-kubectl-example-1.1.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A kubectl-example https://github.com/r-ryantm/nixpkgs/archive/c5648deb83a31c00c71c3b11b50c7f457730eaec.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/h6lmak6r4r0rcg2y0i9hw74mdnzkp71x-kubectl-example-1.1.0
ls -la /nix/store/h6lmak6r4r0rcg2y0i9hw74mdnzkp71x-kubectl-example-1.1.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

kubectl-example

Maintainer pings
cc @bryanasdev000 @kalbasit for testing.

Result of nixpkgs-review pr 154600 run on x86_64-linux 1

1 package built:

kubectl-example

Prints help, LGTM


Clean up AbstractValueDomain/TypeMask queries in dart2js

We have a number of methods on type masks that express type relations by returning bools, which the AbstractValueDomain then wraps as AbstractBools. There are a couple of issues:

In many cases, we can answer a query precisely (in the non-trivial AVD), so true and false can be converted to True and False, but we end up converting one of the results to Maybe instead. (For example, containsType can produce a definite False answer in many cases, but is limited to producing either True or Maybe.)
In some cases, the type mask query can produce false positives or false negatives. A prominent example is containment checks involving union type masks. A true result does genuinely mean True, but false could be a false negative and therefore needs to be converted to Maybe. We do this incorrectly in some cases (e.g. abstractValueDomain.contains()), so our logic is unsound. More generally, we should just enable the type mask queries to answer True, False, or Maybe themselves instead of relying on this conversion from boolean to 3-state logic.

We can also clean up the AVD API itself. For example, there's no reason to have both contains and isIn.
cc @sigmundch @rakudrama

Note that some queries are context dependent. isInterceptor is used mostly in the negative, i.e. if the result isDefinitelyFalse, we can do an optimization. It is not worth any effort do distinguish isDefinitelyTrue from 'isPossiblyTrue`.
Perhaps some of the APIs should be changed to include the may/must attribute in the name, e.g. maybeInterceptor or notInterceptor.
I believe that we can get a precise (True/False/Maybe) result for isInterceptor if we use a different implementation, but we should not require it.


build: Monorepo task orchestration

Task orchestration is getting ridiculous, need some monorepo tooling.
Research into

[ ] nx
[ ] turborepo
[ ] moonrepo

I'm going to spend the time else before wasting more time on this.


example just returns empty array

require('vendor/autoload.php');
use seregazhuk\PinterestBot\Factories\PinterestBot;
$bot = PinterestBot::create();
$pins = $bot->pins->search('cats')->take(100)->toArray();
print_r ($pins);

trying this simple example just returns an empty array. what am i doing wrong?

Hi,
change you command to
$bot->pins->search($query)->take($nbr)->get()

marcesh,
That should work...your command works for me. I suspect its a PHP version problem.


Select input is default option not binded

Not sure if this is a bug but i wonder why the second select input (in the example) is blank on change ?
Vue.js version
2.0.2
Reproduction Link
https://jsfiddle.net/aj6g87dh/1/
What is Expected?
Default option selected or first option selected bby default
What is actually happening?
On change, the second select is blank

The selected option always reflect the value of v-model value which is list. When you switch options, list doesn't change, so nothing in the new options are selected.
You probably want to explicit set list = this.options[0].value in onChange.


Upgrade to docstore 2.x

This brings type/collection-safe get/delete operations.

Upgraded in https://github.com/rla/blog-core/commit/f4433d16a24eb618d97034645e34d7dc3de89551


Ability to show recent month at top.

Right now the recent month is at the bottom of the list. Is it possible to recent month at top
Currently:
May
June
July
Can we do in recent order:
July
June
May

I achieved this by reversing the recyclerview layoutmanger.
(layoutManager as? LinearLayoutManager)?.run {
                reverseLayout = true
                stackFromEnd = true
            }

However it would be nice to have a method to set this property in library like calenderView.isReverseLayout = true

I think only reverseLayout = true should be sufficient?
If this is needed in the library, a PR would be appreciated.


Campaign: Search for a location on the map

As an app user, I can search on all maps for any desired location and have this displayed to me.
The search function searches adresses, local districts, and entire states. (Only) map information can be searched here.
Design:

Prototype: https://www.figma.com/proto/7wE0Iveas3GGb8u4oL0714/App-Design-Mitglieder-App-(1)-(Copy)?node-id=2654-4866&t=b8swD5IOAFfZ0OSo-1&starting-point-node-id=2425%3A17429

Pollion reference: https://github.com/pollion/sunflower-app/issues/21

Please review issue description and move to "Ready for Development" @leagerndt @JuliaFreitagBGSt


Always log out automatically

python3.7 + django2.1
I am not sure if it is my configuration problem, I often log out automatically when I operate the day after tomorrow.
I hope I can get help!

I can't find any answer I want on the Internet. It seems that only I have encountered this problem alone, which makes me very puzzled.


Reintroduce old tests as new tests

Describe the bug
There is a lot of FIXME commented code in the test suite.
To Reproduce
grep "FIXME" tests/*
Expected behavior
No FIXMEs

5 left.
https://github.com/andrew-johnson-4/LSTS/search?q=FIXME


Should asset.getFileUrl() return the full path?

If I try to create a new asset:
var filename = assetName + '.glb';
var file = {
    url: someAsset.getFileUrl(),
    filename: filename
};
var asset = new pc.Asset(filename, 'container', file, null, options);

Where the url is a relative path (e.g '/foobar/bar.glb'), the asset loader will add a prefix (/api/) if in Editor. This causes an issue when the relative path is from an asset in the project (asset.getFileUrl()) and already has the prefix added.
When published, this is not an issue as there is no prefix.
url: window.location.origin + someAsset.getFileUrl();

Should getFileUrl return a full path instead so that there is a parity between the Editor and Published version of the game or check if the prefix is already added?

+1, would be great to have. Maybe an alternative, like getFileFullUrl or something, in case someone already depends on current getFileUrl results.


Simplify file path display

Currently file path includes the full information of the uri, which besides being redundant, causes typescript to try to execute fs requests from directories that don't even exist.

This should be resolved in createUriConverter. If the scheme and authority of the parsed URI are the same as the root folder, the scheme and authority are hidden in fileName.


Not able to perform aspect_hookSelector

I want to hook to UIControl addTarget:action:forControlEvents but not able to
[UIControl aspect_hookSelector:@selector(addTarget:action:forControlEvents:) withOptions:AspectPositionAfter usingBlock:^(id<AspectInfo> aspectInfo, BOOL animated) {
                // the instance getting the callback
                NSLog(@"here");

            } error:&err];

            if (err) {
                NSLog(@"Err %@",err);
            }

But getting this error:
(lldb) po err
Error Domain=AspectErrorDomain Code=6 "Block signature <NSMethodSignature: 0x7fad2dc107e0> doesn't match <NSMethodSignature: 0x7fad2bdf4380>." UserInfo=0x7fad2bdf43c0 {NSLocalizedDescription=Block signature <NSMethodSignature: 0x7fad2dc107e0> doesn't match <NSMethodSignature: 0x7fad2bdf4380>.}

BOOL animated doesn't match the signature above (id,SEL,int)

My bad . sorry...
:)
Copy pasted from the example ....
Thanks for the quick reply!


S3MediaStorage's default save tries to save to local static folder

Currently, S3MediaStorage descends from StaticFilesStorage, which means that files are being put into the static folder once the _save function calls up to super.  As far as I can tell, it isn't using anything that is specific to StaticFilesStorage and works with the FileSystemStorage, which defaults to the media directory.  Furthermore, it may make sense to not call super at all, as with the FileSystemStorage, it attempts to save to the media folder instead of just the S3 bucket.

You're right, we save the media files in two places unnecessarily. Thanks for this @722C.


changed icon color to black solving issue #143

Issue that this pull request solves
#143
Closes: # (issue number)
Proposed changes
Brief description of what is fixed or changed
Types of changes
Put an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update (Documentation content changed)
[ ] Other (please describe):

Checklist
Put an x in the boxes that apply

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] My changes does not break the current system and it passes all the current test cases.

Screenshots

Please attach the screenshots of the changes made in case of change in user interface
Other information
Any other information that is important to this pull request
I am changing the color of icon from grey to black so as to maintain the theme. As the icon used in different page should have same color.

I believe https://github.com/HITK-TECH-Community/Community-Website/issues/143#issuecomment-752852978 answers your query, hence closing this


@ is missing  for required TickerProvider vsync  in AnimationController in version 1.22

After upgrading flutter 1.22  I get error that 'The named parameter 'vsync' isn't defined'. when I check the animationcontroller class I see @ is missing. adding @ solves problem.

Could this be #64260 ?

Could you please post an output of flutter analyze without using the @ sign

Analyzing ulakbelgit...

   info • Unused import: 'package:shared_preferences/shared_preferences.dart' • lib/commons/actions_container.dart:14:8 • unused_import
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          ActionContainer.user, ActionContainer.image, ActionContainer.action, ActionContainer.buttonText, ActionContainer.incident,
          ActionContainer.actions • lib/commons/actions_container.dart:28:7 • must_be_immutable
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          ApplicatorInfo.incident • lib/commons/applicator_info.dart:6:7 • must_be_immutable
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          Attachments.attachments, Attachments.fromInternal, Attachments.size • lib/commons/attachment.dart:7:7 • must_be_immutable
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          CitizenInfo.incidentMap, CitizenInfo.incident, CitizenInfo.valueKey • lib/commons/citizen_info.dart:8:7 • must_be_immutable
   info • Unused import: 'dart:io' • lib/commons/forms.dart:3:8 • unused_import
   info • Unused import: 'package:shared_preferences/shared_preferences.dart' • lib/commons/forms.dart:16:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/controllers/preview_page.dart' • lib/commons/forms.dart:20:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/utils/mainpage_funcs.dart' • lib/commons/forms.dart:28:8 • unused_import
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          FormsContainer.action, FormsContainer.buttonText, FormsContainer.incident • lib/commons/forms.dart:39:7 • must_be_immutable
   info • The value of the local variable 'firstvl' isn't used • lib/commons/forms.dart:254:12 • unused_local_variable
   info • The value of the local variable 'up' isn't used • lib/commons/forms.dart:255:10 • unused_local_variable
   info • The value of the local variable 'value' isn't used • lib/commons/forms.dart:790:29 • unused_local_variable
   info • 'WhitelistingTextInputFormatter' is deprecated and shouldn't be used. Use FilteringTextInputFormatter.allow instead. This feature was
          deprecated after v1.20.0-1.0.pre. • lib/commons/forms.dart:927:32 • deprecated_member_use
   info • 'digitsOnly' is deprecated and shouldn't be used. Use FilteringTextInputFormatter.digitsOnly instead. This feature was deprecated after
          v1.20.0-1.0.pre. • lib/commons/forms.dart:927:63 • deprecated_member_use
   info • Avoid using braces in interpolation when not needed • lib/commons/forms.dart:1388:46 • unnecessary_brace_in_string_interps
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          PickerWidget.mediaFiles • lib/commons/gallery.dart:18:7 • must_be_immutable
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          GalleryWidget.paths • lib/commons/gallery.dart:158:7 • must_be_immutable
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          LocalPreview.file • lib/commons/gallery.dart:297:7 • must_be_immutable
   info • Unused import: 'package:google_map_location_picker/google_map_location_picker.dart' • lib/commons/map.dart:2:8 • unused_import
   info • Unused import: 'package:dio/dio.dart' • lib/controllers/annuncement_folder/all_announcements.dart:5:8 • unused_import
   info • Unused import: 'package:pull_to_refresh/pull_to_refresh.dart' • lib/controllers/annuncement_folder/all_announcements.dart:8:8 •
          unused_import
   info • Unused import: 'package:ulakbelmobil/commons/custom_bottomsheet.dart' • lib/controllers/annuncement_folder/all_announcements.dart:9:8 •
          unused_import
   info • 'title' is deprecated and shouldn't be used. Use "label" instead, as it allows for an improved text-scaling experience. This feature was
          deprecated after v1.19.0. • lib/controllers/annuncement_folder/announcements.dart:74:9 • deprecated_member_use
   info • Equality operator `==` invocation with references of unrelated types • lib/controllers/call_connect.dart:268:11 •
          unrelated_type_equality_checks
   info • Unused import: 'package:hive/hive.dart' • lib/controllers/customs_folder/customs_details.dart:14:8 • unused_import
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          CustomsMessageDetailsPage.id, CustomsMessageDetailsPage.accountId, CustomsMessageDetailsPage.title •
          lib/controllers/customs_folder/customs_details.dart:40:7 • must_be_immutable
   info • Avoid using braces in interpolation when not needed • lib/controllers/customs_folder/customs_details.dart:926:42 •
          unnecessary_brace_in_string_interps
   info • Unused import: 'package:ulakbelmobil/controllers/profile/fast_answer_list.dart' • lib/controllers/enterence.dart:15:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/modal/application_prefs.dart' • lib/controllers/enterence.dart:17:8 • unused_import
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          MyApp.analytics, MyApp.observer • lib/controllers/enterence.dart:21:7 • must_be_immutable
   info • Avoid using braces in interpolation when not needed • lib/controllers/fax_folder/create_fax_page.dart:306:9 •
          unnecessary_brace_in_string_interps
   info • The value of the field '_loading' isn't used • lib/controllers/fax_folder/received_faxes.dart:26:8 • unused_field
   info • This function has a return type of 'FutureOr<List<Fax>>', but doesn't end with a return statement •
          lib/controllers/fax_folder/received_faxes.dart:53:21 • missing_return
   info • The value of the local variable 'response' isn't used • lib/controllers/fax_folder/received_faxes.dart:71:28 • unused_local_variable
   info • This function has a return type of 'Widget', but doesn't end with a return statement •
          lib/controllers/fax_folder/received_faxes.dart:95:20 • missing_return
   info • The value of the field '_loading' isn't used • lib/controllers/fax_folder/sended_faxes.dart:24:8 • unused_field
   info • The method doesn't override an inherited method • lib/controllers/fax_folder/sended_faxes.dart:40:21 • override_on_non_overriding_member
   info • This function has a return type of 'FutureOr<List<Fax>>', but doesn't end with a return statement •
          lib/controllers/fax_folder/sended_faxes.dart:40:21 • missing_return
   info • The value of the local variable 'response' isn't used • lib/controllers/fax_folder/sended_faxes.dart:59:28 • unused_local_variable
   info • The value of the local variable 'localName' isn't used • lib/controllers/fax_folder/sended_faxes.dart:101:42 • unused_local_variable
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          IncidentFormsPage.sourceId, IncidentFormsPage.internal, IncidentFormsPage.from, IncidentFormsPage.info •
          lib/controllers/incident_create_forms.dart:38:7 • must_be_immutable
   info • The type parameter 'internal' is annotated with @required but only named parameters without a default value can be annotated with it •
          lib/controllers/incident_create_forms.dart:48:5 • invalid_required_named_param
   info • The value of the field '_checkingDist' isn't used • lib/controllers/incident_create_forms.dart:96:8 • unused_field
   info • The value of the field '_checkingStrt' isn't used • lib/controllers/incident_create_forms.dart:97:8 • unused_field
   info • Avoid using braces in interpolation when not needed • lib/controllers/incident_create_forms.dart:1036:48 •
          unnecessary_brace_in_string_interps
   info • This function has a return type of 'String', but doesn't end with a return statement • lib/controllers/incident_create_forms.dart:1254:10
          • missing_return
   info • The value of the local variable 'widget' isn't used • lib/controllers/incident_create_forms.dart:1885:11 • unused_local_variable
   info • 'WhitelistingTextInputFormatter' is deprecated and shouldn't be used. Use FilteringTextInputFormatter.allow instead. This feature was
          deprecated after v1.20.0-1.0.pre. • lib/controllers/incident_create_forms.dart:2129:26 • deprecated_member_use
   info • 'digitsOnly' is deprecated and shouldn't be used. Use FilteringTextInputFormatter.digitsOnly instead. This feature was deprecated after
          v1.20.0-1.0.pre. • lib/controllers/incident_create_forms.dart:2129:57 • deprecated_member_use
   info • Unused import: 'package:path_provider/path_provider.dart' • lib/controllers/incident_details.dart:9:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/commons/custom_bottomsheet.dart' • lib/controllers/incident_details.dart:15:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/commons/hero_dialog_route.dart' • lib/controllers/incident_details.dart:17:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/controllers/preview_page.dart' • lib/controllers/incident_details.dart:19:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/main.dart' • lib/controllers/incident_details.dart:21:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/modal/identity_information.dart' • lib/controllers/incident_details.dart:22:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/utils/global_functions.dart' • lib/controllers/incident_details.dart:26:8 • unused_import
   info • The value of the field '_incidentActions' isn't used • lib/controllers/incident_details.dart:148:19 • unused_field
   info • This function has a return type of 'FutureOr<List<dynamic>>', but doesn't end with a return statement •
          lib/controllers/incident_details.dart:409:16 • missing_return
   info • 'title' is deprecated and shouldn't be used. Use "label" instead, as it allows for an improved text-scaling experience. This feature was
          deprecated after v1.19.0. • lib/controllers/incident_details.dart:572:13 • deprecated_member_use
   info • 'title' is deprecated and shouldn't be used. Use "label" instead, as it allows for an improved text-scaling experience. This feature was
          deprecated after v1.19.0. • lib/controllers/incident_details.dart:586:13 • deprecated_member_use
   info • 'title' is deprecated and shouldn't be used. Use "label" instead, as it allows for an improved text-scaling experience. This feature was
          deprecated after v1.19.0. • lib/controllers/incident_details.dart:594:11 • deprecated_member_use
   info • 'title' is deprecated and shouldn't be used. Use "label" instead, as it allows for an improved text-scaling experience. This feature was
          deprecated after v1.19.0. • lib/controllers/incident_details.dart:608:11 • deprecated_member_use
   info • This function has a return type of 'Widget', but doesn't end with a return statement • lib/controllers/incident_details.dart:1369:10 •
          missing_return
   info • This function has a return type of 'String', but doesn't end with a return statement • lib/controllers/new_internal.dart:242:10 •
          missing_return
   info • Avoid using braces in interpolation when not needed • lib/controllers/new_internal.dart:771:49 • unnecessary_brace_in_string_interps
   info • Unused import: 'package:shared_preferences/shared_preferences.dart' • lib/controllers/new_login.dart:9:8 • unused_import
   info • The value of the field 'platform' isn't used • lib/controllers/new_login.dart:26:16 • unused_field
   info • 'WhitelistingTextInputFormatter' is deprecated and shouldn't be used. Use FilteringTextInputFormatter.allow instead. This feature was
          deprecated after v1.20.0-1.0.pre. • lib/controllers/new_login.dart:107:9 • deprecated_member_use
   info • 'digitsOnly' is deprecated and shouldn't be used. Use FilteringTextInputFormatter.digitsOnly instead. This feature was deprecated after
          v1.20.0-1.0.pre. • lib/controllers/new_login.dart:107:40 • deprecated_member_use
   info • Unused import: 'package:ulakbelmobil/utils/global_functions.dart' • lib/controllers/new_mainPage.dart:28:8 • unused_import
   info • Unused import: 'package:url_launcher/url_launcher.dart' • lib/controllers/new_mainPage.dart:41:8 • unused_import
   info • The value of the field '_statusSelected' isn't used • lib/controllers/new_mainPage.dart:132:25 • unused_field
   info • The value of the field '_sourceSelected' isn't used • lib/controllers/new_mainPage.dart:133:25 • unused_field
warning • The parameter 'vsync' is required • lib/controllers/new_mainPage.dart:280:9 • missing_required_param
   info • This function has a return type of 'Widget', but doesn't end with a return statement • lib/controllers/new_mainPage.dart:514:10 •
          missing_return
   info • 'title' is deprecated and shouldn't be used. Use "label" instead, as it allows for an improved text-scaling experience. This feature was
          deprecated after v1.19.0. • lib/controllers/new_mainPage.dart:1161:31 • deprecated_member_use
   info • 'title' is deprecated and shouldn't be used. Use "label" instead, as it allows for an improved text-scaling experience. This feature was
          deprecated after v1.19.0. • lib/controllers/new_mainPage.dart:1168:31 • deprecated_member_use
   info • Unused import: 'dart:math' • lib/controllers/otp_page.dart:3:8 • unused_import
   info • Unused import: 'package:async/async.dart' • lib/controllers/otp_page.dart:14:8 • unused_import
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          OTPPage.mainFunctions • lib/controllers/otp_page.dart:18:7 • must_be_immutable
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          TimerWidget.data, TimerWidget.index • lib/controllers/otp_page.dart:274:7 • must_be_immutable
   info • Unused import: 'package:photo_view/photo_view_gallery.dart' • lib/controllers/preview_page.dart:12:8 • unused_import
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          PreviewPage.local, PreviewPage.tur, PreviewPage.attachments, PreviewPage.chosen • lib/controllers/preview_page.dart:21:7 •
          must_be_immutable
   info • Avoid using braces in interpolation when not needed • lib/controllers/preview_page.dart:166:42 • unnecessary_brace_in_string_interps
   info • Unused import: 'package:otp/otp.dart' • lib/controllers/profile/settings.dart:7:8 • unused_import
   info • Unused import: 'package:path_provider/path_provider.dart' • lib/controllers/profile/settings.dart:8:8 • unused_import
   info • This function has a return type of 'Widget', but doesn't end with a return statement • lib/controllers/profile/user_profile.dart:616:10 •
          missing_return
   info • 'pickImage' is deprecated and shouldn't be used. Use imagePicker.getImage() method instead. •
          lib/controllers/profile/user_profile.dart:676:35 • deprecated_member_use
   info • Avoid using braces in interpolation when not needed • lib/controllers/profile/user_profile.dart:786:47 •
          unnecessary_brace_in_string_interps
   info • 'subhead' is deprecated and shouldn't be used. This is the term used in the 2014 version of material design. The modern term is subtitle1.
          This feature was deprecated after v1.13.8. • lib/custom_expantion_tile.dart:169:24 • deprecated_member_use
   info • 'subhead' is deprecated and shouldn't be used. This is the term used in the 2014 version of material design. The modern term is subtitle1.
          This feature was deprecated after v1.13.8. • lib/custom_expantion_tile.dart:200:33 • deprecated_member_use
   info • Unused import: 'package:flutter/material.dart' • lib/modal/application_prefs.dart:1:8 • unused_import
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          FlipClock._digitBuilder, FlipClock._separator, FlipClock.timeLeft • lib/sudoku/flip.dart:21:7 • must_be_immutable
   info • Name non-constant identifiers using lowerCamelCase • lib/sudoku/flip.dart:301:35 • non_constant_identifier_names
   info • Name non-constant identifiers using lowerCamelCase • lib/sudoku/flip.dart:306:37 • non_constant_identifier_names
   info • Unused import: 'package:characters/characters.dart' • lib/sudoku/sudoku.dart:5:8 • unused_import
   info • Unused import: 'package:flutter/material.dart' • lib/utils/filter_options.dart:1:8 • unused_import
   info • Unused import: 'dart:math' • lib/utils/global_functions.dart:3:8 • unused_import
   info • Unused import: 'package:awesome_dialog/awesome_dialog.dart' • lib/utils/global_functions.dart:5:8 • unused_import
   info • Unused import: 'package:font_awesome_flutter/font_awesome_flutter.dart' • lib/utils/global_functions.dart:13:8 • unused_import
   info • Unused import: 'package:location/location.dart' • lib/utils/global_functions.dart:19:8 • unused_import
   info • Unused import: 'package:sentry/sentry.dart' • lib/utils/global_functions.dart:21:8 • unused_import
   info • Unused import: 'package:ulakbelmobil/modal/new_created.dart' • lib/utils/global_functions.dart:27:8 • unused_import
   info • Unused import: '../main.dart' • lib/utils/global_functions.dart:32:8 • unused_import
   info • This function has a return type of 'Future<dynamic>', but doesn't end with a return statement • lib/utils/global_functions.dart:96:10 •
          missing_return
   info • This function has a return type of 'Widget', but doesn't end with a return statement • lib/utils/global_functions.dart:667:26 •
          missing_return
   info • This function has a return type of 'FutureOr<bool>', but doesn't end with a return statement • lib/utils/global_functions.dart:1544:16 •
          missing_return
   info • Avoid using braces in interpolation when not needed • lib/utils/global_functions.dart:1561:50 • unnecessary_brace_in_string_interps
   info • Avoid using braces in interpolation when not needed • lib/utils/global_functions.dart:1626:54 • unnecessary_brace_in_string_interps
   info • The stack trace variable 'stackTrace' isn't used and can be removed • lib/utils/global_functions.dart:1648:21 • unused_catch_stack
   info • This function has a return type of 'FutureOr<LocationData>', but doesn't end with a return statement • lib/utils/globals.dart:251:24 •
          missing_return
   info • The exception variable 'e' isn't used, so the 'catch' clause can be removed • lib/utils/globals.dart:396:33 • unused_catch_clause
   info • Unused import: 'dart:async' • lib/utils/logout.dart:1:8 • unused_import
   info • This function has a return type of 'FutureOr<List<Department>>', but doesn't end with a return statement •
          lib/utils/mainpage_funcs.dart:299:28 • missing_return
   info • This function has a return type of 'FutureOr<List<User>>', but doesn't end with a return statement • lib/utils/mainpage_funcs.dart:385:22
          • missing_return
   info • This function has a return type of 'FutureOr<List<IncidentTopic>>', but doesn't end with a return statement •
          lib/utils/mainpage_funcs.dart:476:31 • missing_return
   info • This function has a return type of 'FutureOr<List<FastResponse>>', but doesn't end with a return statement •
          lib/utils/mainpage_funcs.dart:584:30 • missing_return
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          CustomAppBar.preferredSize • lib/widgets/appbar.dart:8:7 • must_be_immutable
   info • Unused import: 'package:ulakbelmobil/modal/incident.dart' • lib/widgets/attachment.dart:13:8 • unused_import
   info • Avoid using braces in interpolation when not needed • lib/widgets/attachment.dart:174:42 • unnecessary_brace_in_string_interps
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          ConstrainedTextField.model, ConstrainedTextField.hintText, ConstrainedTextField.max, ConstrainedTextField.controller,
          ConstrainedTextField.focusNode • lib/widgets/constrained.dart:4:7 • must_be_immutable
   info • Unused import: 'package:ulakbelmobil/modal/action_forms.dart' • lib/widgets/datetime_picker.dart:6:8 • unused_import
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          DateTimePickerWidget.requestPayload, DateTimePickerWidget.custom, DateTimePickerWidget.field, DateTimePickerWidget.postpone •
          lib/widgets/datetime_picker.dart:10:7 • must_be_immutable
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          ExpandableTile.incident • lib/widgets/expandable_tile.dart:7:7 • must_be_immutable
   info • 'body1' is deprecated and shouldn't be used. This is the term used in the 2014 version of material design. The modern term is bodyText2.
          This feature was deprecated after v1.13.8. • lib/widgets/expandable_tile.dart:48:22 • deprecated_member_use
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          ProfilePhoto.radius • lib/widgets/profilePhoto.dart:6:7 • must_be_immutable
   info • This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final:
          ConstraintTextWidget.title, ConstraintTextWidget.controller, ConstraintTextWidget.focusNode, ConstraintTextWidget.min,
          ConstraintTextWidget.max, ConstraintTextWidget.suffix • lib/widgets/textWidgets.dart:8:7 • must_be_immutable
   info • This function has a return type of 'bool', but doesn't end with a return statement • lib/widgets/textWidgets.dart:150:33 • missing_return
   info • 'WhitelistingTextInputFormatter' is deprecated and shouldn't be used. Use FilteringTextInputFormatter.allow instead. This feature was
          deprecated after v1.20.0-1.0.pre. • lib/widgets/textWidgets.dart:209:28 • deprecated_member_use
   info • 'digitsOnly' is deprecated and shouldn't be used. Use FilteringTextInputFormatter.digitsOnly instead. This feature was deprecated after
          v1.20.0-1.0.pre. • lib/widgets/textWidgets.dart:209:59 • deprecated_member_use

@xyzbilal , the output gives you a warning that the parameter vsync is missing. Could you please add it? Or is it still the same as it is given in the image?

Looks like a duplicate of #63486

I already solved my problem. I just wanted to report the problem that is @ missing for vsync parameter.

flutter clean
reopen vscode

animation_controller.dart
AnimationController({     double? value,     this.duration,     this.reverseDuration,     this.debugLabel,     this.lowerBound = 0.0,     this.upperBound = 1.0,     this.animationBehavior = AnimationBehavior.normal,     required TickerProvider vsync,   }) : assert(lowerBound != null),        assert(upperBound != null),        assert(upperBound >= lowerBound),        assert(vsync != null),        _direction = _AnimationDirection.forward {     _ticker = vsync.createTicker(_tick);     _internalSetValue(value ?? lowerBound);   }
The "required" is missing @ annotation.

@hosseinsohan

@ is not missing in required
Originally posted by PixelToast
With NNBD consider the following:
class Foo {
final int foo;
Foo({this.foo});
}
This is invalid because foo is optional and has no default value, you can't assign null to a field that is not nullable.
Before NNBD we would just give it the @required annotation, which allowed the analyzer to generate a warning if it's not supplied, but a warning is just a warning and makes no runtime guarantees.
Because of this, required needed to become a first class language feature rather than just a lint.


Clinical Significance is not displaying

When clicking on an evidence item, the clinical significance field is blank.

This looks like an issue with the spreadsheet - the column is named "Clinical Signficance" I'll fix the typo and prepare a new data dump.

Ha... My bad.

Ha, no worries, I should have caught it too! Pushing the fix to master shortly.


Question on how to extend

Hi there,
Great component, thanks!  I had a quick question: I'd like to create a bottom sheet that has multiple "snap points". A good example of what I'm trying to achieve is https://github.com/wix/react-native-interactable
A small flick would bring the bottom sheet to it's first position, but you can drag it further to the top position. And a gesture with more force would move it immediately to the top/bottom.
Is this something you reckon is easily added to this react-swipeable-bottom-sheet? Or should I look at writing my own based off of the swipeable views?
/Thanks
Jelte

Up


Error "can not require"

When validating https://vannes-gbfs.klervi.net/gbfs/2/gbfs.json we get this error message.
Example: https://gbfs-validator.netlify.app/?url=https%3A%2F%2Fvannes-gbfs.klervi.net%2Fgbfs%2F2%2Fgbfs.json

Ok, multiple errors.
The feed is invalid. The version is missing on the gbfs.json file.
The validator attempt to validate on v1.0 (because no version).
And try to validate gbfs_versions file. This file should be exists on v1.0, #81 fix that.
If you force the v2.3, an error from the schema is returned. I ll made another PR with the latest schemas (https://github.com/MobilityData/gbfs-json-schema/commit/5ac5522e029356b10c4b35972eb84f6499ed60d2)


Filtering the filters

I have a request to add a feature that can filter the filters as we search in the table.
For instance when we use this page DOM_source_select2.html and search for Some Data 2 then the Tags filter shows all the tags. Instead, I request it should only load the related data for the search.
so like in excel when we apply a filter in one column the filters of other column are also filtered something similar to that.
Let me know if we can take this in the main js file.

take a look at the cumulative_filtering option? http://yadcf-showcase.appspot.com/cumulative_filtering.html ?


ptime: time.clock back-compatibility with python 3.10

🐛 Bug
In the ptime module:
time.clock() is no longer available in python >= 3.8
The Windows back-compatibility code causes an issue when Python version >= 3.10
To Reproduce
This issue occurs in Windows with Python 3.10
e.g.:
import napari
viewer = napari.view_image(image)

Result
...
File "C:\Users\Y\miniconda3\envs\Napari\lib\site-packages\vispy\util\ptime.py", line 36, in
cstart = systime.clock()  # Required to start the clock in windows
AttributeError: module 'time' has no attribute 'clock'
Additional context
This section fails on Windows if python version >= 3.10 because of string comparison: '3.10' < '3.3' = True
if sys.platform.startswith('win') and sys.version < '3.3':
    cstart = systime.clock()  # Required to start the clock in windows

Where this code with comparison is in the napari codebase?

Hi @Czaki thanks for the quick response.
As in the post above:
C:\Users\Y\miniconda3\envs\Napari\lib\site-packages\vispy\util\ptime.py", line 36
The comparison is in the line before that, line 35.

Actually, this may be in the vispy package instead!

I just checked the vispy repository and did not see such a line here.
https://github.com/vispy/vispy/blob/859fcaedcc54ebe1ecfd21348cefa37a1cf08ca6/vispy/util/ptime.py
What version of vispy did you have installed?

Ok. They remove it in 0.9 version, and recent napari versions require 0.9 or 0.10.
If you need to use old napari/vispy versions, then use also older python releases, as more things may not work.

Hi @Czaki,
Thank you for the advice, I think I have a broken conda env as it indeed reports an older vispy version as latest (0.7.3) for unkown reason.
Apologies for this - please feel free to remove this issue.


Update to latest Mirage3 FS

One of the CI error should be fixed by https://github.com/mirage/mirage-dev/pull/243
The other one is a bit more annoying: https://travis-ci.org/mirage/ocaml-git/jobs/183105501
On 4.02 we have a lot of hard failures which are not track correctly by the available field:

dns.dev~mirage
mirage-clock-unix.dev~mirage
mirage-flow.dev~mirage
mirage-vnetif.dev~mirage

And lots of breakage on 4.03 and Windows too: https://ci.appveyor.com/project/samoht/irmin/build/1.0.136
boohoohoo

The 4.02 errors are fixed by https://github.com/mirage/mirage-dev/pull/244 and https://github.com/mirage/mirage-dev/pull/245 and possibly. One new error appeared while compiling tcpip with mirage-unix.dev~mirage which should be fixed by https://github.com/ocaml/opam-repository/pull/8094
The irmin-unix errors are fixed by https://github.com/ocaml/opam-repository/pull/8092 and https://github.com/ocaml/opam-repository/pull/8090

Jobs restarted.


Provide dummies with sidecar containers

Depends on https://github.com/elifesciences/builder-base-formula/pull/118
Basic, disabled pillars have been provided with https://github.com/elifesciences/builder-private/commit/e5422f03924335ebd9f1fc9f0906cb3dd698bf83

Can't build without the builder-base-formula part, of course.


Loading services from dict

Add method for loading services from dictionary.
Tests included.

Fixes: #159

What about GitHub application? Do we want to support it also?

What about GitHub application? Do we want to support it also?

It should be supported as well -- I'll add it to the test as well.

I've added tokens and other info to __str__ methods. Is there anyone against this approach?
(I am using the __str__ in __hash__ implementation to allow working with sets of services.)

I'm personally still waiting for the documentation :)

I'm personally still waiting for the documentation :)

Sorry. I've been out for some time. (The docs were missing because I wanted to wait for the final design. I'll update the PR today.)

I'm personally still waiting for the documentation :)

@TomasTomecek PTAL


Improve docs of convolution_2d

This is PR for improving docs of functions/links. Related issue: #2182
Modified functions/links:

functions/connection/convolution_2d

Doctest result is here.
Document: reference/functions
-----------------------------
1 items passed all tests:
 106 tests in default
106 tests in 1 items.
106 passed and 0 failed.
Test passed.

I fixed the documents. Please merge after the test.

LGTM


Faster loading folders

Hello.
I have noticed that the first time you enter the mounted folder it takes a while to load.
Consecutive loads of the same folder (while metadata is still valid, are performed really fast) but after some time, it needs to reload it again.
This behavior is the same for every folder and subfolder in the mounted directory.
While understandable, I find it really slow and it gives the whole application a feeling really unresponsive while loading the metadata
Is there any way to improve the metadata retrieval so the application doesn't feel so unresponsive, specially for simple operations such as ls and navigation of folders?

No, sorry, there is no way to make the metadata fetching faster.

I am just trying to understand the behavior of why sometimes it's really slow and other times really faster.
Could the metadata be fetched in the background when the folder is mounted and then be ready for when any operation is performed?

I am just trying to understand the behavior of why sometimes it's really slow and other times really faster.

I think it depends on the access pattern. Sometimes the OS issues a stat call to a dir or a file (maybe to get completion arguments), so when you actually need the metadata it's already there.

Could the metadata be fetched in the background when the folder is mounted and then be ready for when any operation is performed?

At the moment it isn't so. But it can be an enhancement.

In version 0.7.21 (that I'm publishing right now), I've added background_folder_fetching config option to start a background thread that fetches folder data. Let me know is this solve your issue.

Is it possible to cache this metadata somehow?
Each time you access a folder in which there have not even been changes, a rescan takes place, if the folder is large, it takes a long time.
It may be possible to add options with different scenarios such as:
Download a list of all files when mounting - it would be convenient to wait once, and know that the folders will open quickly.
Download lazily (it’s already possible now)
Use cache past scan? (Is this possible?


[engsys] Migrate to tox4

Description
This pull request migrates this repository's tox config to be compatible with tox 4. Major changes include:

All references to tox-monorepo were removed in the repository. tox4 adds native support for the use-case that tox-monorepo enables: --root allows for {toxinidir} to be specified indepedently of the location of tox.ini.
Documentation was updated to use tox4-isms: use --root in examples, call out that default values for the config file and root can be set with environment variables, etc...
tox_harness.py was updated to use --root when invoking tox
A smattering of refactors to tox.ini to clean it up

As many paths as possible were re-written relative to repository root. (Uses a local tox plugin (toxfile.py) to compute the repository root)
Deprecated and/or unnecessary config keys were updated.

This PR is part of an ongoing effort by the ML team to make azure-sdk-for-python's tooling more convenient for use during local development (Not a high priority workstream).
cc: @scbedd
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

Laurent opened a PR (https://github.com/Azure/autorest.python/pull/1700) to upgrade to tox 4 in autorest, and based on his work it seems we'd have to:

Update instances of tox -e to tox run -e
Change the format of git installations from, for example:

git+https://github.com/Azure/azure-sdk-for-python#subdirectory=scripts/pylint_custom_plugin&egg=pylint-guidelines-checker

to
pylint-guidelines-checker @ git+https://github.com/Azure/azure-sdk-for-python#subdirectory=scripts/pylint_custom_plugin

Update requests requirements to at least 2.28.2

Update instances of tox -e to tox run -e

This doesn't appear to be a firm requirement: tox will fall back to the tox3 interface (tox -e env_name) if the invocation doesn't match the tox4 interface (tox run -e env_name) (see documentation)

Change the format of git installations from, for example:

git+https://github.com/Azure/azure-sdk-for-python#subdirectory=scripts/pylint_custom_plugin&egg=pylint-guidelines-checker

to
pylint-guidelines-checker @ git+https://github.com/Azure/azure-sdk-for-python#subdirectory=scripts/pylint_custom_plugin

These are the only occurrences I could find of something that looks like a git requirement in the repository, and I don't think tox would interface directly would either (I may be wrong).

https://github.com/Azure/azure-sdk-for-python/blob/e5f49e5d64a507fb2c81f35e05e5fd34193c1a32/tools/azure-sdk-tools/packaging_tools/drop_tools.py#L121-L123
https://github.com/Azure/azure-sdk-for-python/blob/main/eng/pipelines/templates/jobs/update_pr.yml#L23

Update instances of tox -e to tox run -e

Resolved by https://github.com/Azure/azure-sdk-for-python/pull/30159/commits/4efb01ea5d57380ee805e11c1f777d247ab84837 and https://github.com/Azure/azure-sdk-for-python/pull/30159/commits/4cbd85a7b7c3e0dc92700830a7b3b4f2114c5ac6

Another thing that's visible is that we are seeing timeouts again when installing.
There has to be something that isn't shared properly in the new tox, which is why we see these really super long timeouts in CI. It's a deadlock between two tox environments running in parallel :(

Another thing that's visible is that we are seeing timeouts again when installing.
There has to be something that isn't shared properly in the new tox, which is why we see these really super long timeouts in CI. It's a deadlock between two tox environments running in parallel :(

Do you happen to know what the issue was the last time you dealt with this?

API change check
API changes are not detected in this pull request.

Another thing that's visible is that we are seeing timeouts again when installing.
There has to be something that isn't shared properly in the new tox, which is why we see these really super long timeouts in CI. It's a deadlock between two tox environments running in parallel :(

Do you happen to know what the issue was the last time you dealt with this?

It was a long painful process of nailing down every single possible file lock.

We're v close now!

Nice!

Just FYI we won't be merging this even if it's green until next week at the least. We're in a release window right now and I don't like to introduce any eng code changes around this time.

Works for me, there's no rush on my end.

[x]  Why is videoanalyzer CI timing out so badly? Fix it!

I believe I added a commit that resolves this. azure-media-videoanalyzer-edge dev_requirements included tox>4.4.X, which was causing us to attempt to install tox within a tox venv. Pretty clear that's where the massive timeout was coming from.

Wow, I would've imagined that it trivially satisfies that installation requirement (I think tox bootstraps itself into a virtualenv, but I may be wrong).

Wow, I would've imagined that it trivially satisfies that installation requirement (I think tox bootstraps itself into a virtualenv, but I may be wrong).

At the end of the day it's just using pip to install within the environment, so there is no place to prevent that install loop from going wrong. I'm almost certain this is related to a file lock someplace. Regardless, cutting that entry resolves the issue. I think we're probably ok on the parallel access problem I thought may be present.

I will run regression and nightly alpha checks tomorrow, then we will be in the clear to merge this next week! 🚀 🚀 🚀 🚀 🚀 🚀 🚀 🚀

@kdestin We are GREEN! Regress tests + nightly alpha versions all seem to be working appropriately!
I'm a bit disturbed by the consistent credscan stack overflow, but I don't think that's related to this PR at all. Let's see where releases are come monday, then make an announcement and merge it!
Thank you so much for all the effort on this @kdestin ! This is a gigantic necessary contribution that is not at all fun to slog through 👍

/azp run python - core - ci


Ability to set dynamic charge current.

For users with solar and / or battery storage it would be useful to set the dynamic charge current on a circuit, this would allow a Node-Red flow to monitor excess solar then apportion the available excess to a circuit to dump the excess into an EV rather than going out to export.
Easee provides an API for this: https://developer.easee.cloud/reference/post_api-sites-siteid-circuits-circuitid-dynamiccurrent
Note however the API is against a site and circuit combination and not on a charger, so might be better to add to a new node type of "Circuit" as opposed to the existing "Charger" node.
Thanks!
Neil.

Hi,
I have now updated the main node to be more "flexible".
You can now both pre-set variables for charger, site and circuit, or send them in as variables.
In addition, by using the custom command option (see the new readme) you can send about every command in the documentation if you know the endpoint and body set-up.
/Jon

Brilliant, thanks Jon!
It looks like there's a typo in easee-rest-client.js with "stop_charging" entered twice in place of "start_charging". I'll add an issue. I also don't seem to be able to pause charging and get:
"/chargers/UKXXXX0YY/commands/pause_charging POST failed: Error: REST Command failed (400: Bad Request), check console for errors." and the Error label states "GET: Failed" which I assume should be "POST: Failed", I'll do some more testing on why that might be failing as I'm not currently charging.


MxGraph Search option

The search option is working for a complete word only.
For example if we give "rectang" it wont search. It needs a word like "rectangle" to search.
Is there any option to search with partial word

Not at this time.


Double right clicking terminal on windows shows context menu

It's meant to copy then paste and drop selection.

can you please tell me what exactly is the issue and how can is solve it!
i am new to open source.


Control plane migration: shoot specific owner ids for DNS entries

What would you like to be added:
Gardener and dns-shoot-service should add shoot specific owner ids for their managed DNS entries and corresponding DNS owner objects to allow a smooth control plane migration.
Why is this needed:
Both Gardener and the dns-shoot-service manage DNS entries in the control plane of the shoot. If the control plane is moved to another seed, it must not happen, that DNS entries (or more important the corresponding DNS records in the DNS backend) are deleted during intermediate states. Even if they will be recreated later, this would result in unavailable services in the shoot.
There are two controllers generating DNS entries for the shoot: the gardenlet responsible for the API server and INGRESS DNS entries, and the dns shoot service managing entry objects for services and ingresses in the shoot.
There are several aspects to be considered:

Only one DNS controller must be responsible for managing DNS entries for a shoot. This should already be handled by some hand-over mechanism of Gardener (see issue #1631)
The DNS controller taking over responsibility must reconcile all DNS entries of the shoot, before it takes ownership of them. Otherwise it can happen, that it starts deleting DNS records of still unreconciled and therefor unknown DNS entry objects. As there are two controllers managing shoot related DNS entries, each needs an own owner ID.

** Suggested owner ids **
The owner id must be globally unique for each shoot and managing controller. Therefore it must contain

the Garden ID
the project name
the shoot name
the managing controller
The managing controller is needed, as the creation of the DNS owner is used as sync point after all DNS entries which must be migrated are written.

There is already a shoot id used as label key in the shoot-dns-service, which can be reused as a basis.
It has the form: <garden-id>.gardener.cloud/<shoot-namespace>
It is suggested to append /core for Gardener and /dns-shoot for dns-shoot-service respectively.

/cc @mandelsoft
/cc @rfranzke

Hm, I'm confused. If you would use <garden-id>.gardener.cloud/<shoot-namespace>/<some-suffix> as owner ID, how can you then move the responsibility for the DNS entries to a new seed? I don't see any seed identifier encoded in the owner ID.
(Just for reference, looking at what we have today, the TXT record with the owner ID is seed.gardener.cloud/<garden-id>/<shoot-name>.)
If I understand correctly, this issue is about the following things:

Define what the garden ID is (today, we are using the uid of  the garden namespace in the garden cluster, see https://github.com/gardener/gardener/blob/master/pkg/gardenlet/controller/controllerinstallation/controllerinstallation_control.go#L226-L228)
Define what the seed ID is (today, we are using the name of the Seed resource)
Enhance the gardenlet to write the DNSOwner resource as part of shoot reconciliation/deletion flows
(Enhance the shoot-dns-service to write the DNSOwner resource as part of its reconciliation [though, out-of-scope of this issue, please open a separate one at https://github.com/gardener/gardener-extension-shoot-dns-service once clarified how the ID should look like])

Is this summary correct?

It can be migrated * because* there is no seed identifier in the owner id.

@MartinWeindel do you know whether there is a relevant length limit for text record entries?

Strings in SPF and TXT records should be no longer than 255 characters. However to get around this limitation, per RFC 4408 a TXT or SPF record is allowed to contain multiple strings, which should be concatenated together by the reading application.

It can be migrated because there is no seed identifier in the owner id.

Can you explain more? Doesn't not encoding a seed identifier in it lead to the risk that multiple DNS providers act on the same DNS records simultaneously?

If we would have a defined shoot-id (may be including somehow project and shoot name to be meaningful for human beings) this id could also be the basis for the owner ids.

Do you have concrete suggestions? We have .status.uid and .status.technicalID in the ShootStatus at this point in time.

If the owner id would be seed specific , then changing the seed responsibility would result in dangling DNS records, because the DNS controller on the new seed is not responsible. Even worse, if the old controller is still responsible for the owner id , the DNS record would be deleted and then later on recreated by the new controller.
To avoid this the DNS entries need a stable owner id that is bound to the shoot, not to the seed implementing the control plane of the shoot. This allows for a seamless migration of the responsibility.
To avoid a parallel responsibility, the owner object for the shoot on the old seed must  deleted before it is created on the new seed. In case of a regular migration this is ensured by the migration mechanism. In case of a fail-over scenario, we discussed (in Sofia) the lease mechanism with a dedicated timeout. So, if the lease is not renewed, the controller keeps its fingers off those entries.
This mechanism still has to be implemented, but you mentioned, that the fail-over is not in the scope yet

OK, thanks for clarifying, makes perfect sense.
Let's go back to the concrete problem solution: You suggested <garden-id>.gardener.cloud/<shoot-namespace> as ID - the easiest would be to simply keep what we have today: <garden-id>=<uid-of-garden-namespace>. Or do you suggest something else? You also mentioned that the garden ID should be added to the extensions.gardener.cloud/v1alpha1.Cluster resource. How would that look like?

For the garden identity we've used so far the UID of the garden namespace in the virtual garden cluster. This seems to be ok. The seed identity is not handled uniformly today. may be the seed name plus the UID of the seed object plus the garden id should be incorporated. To avoid long names, it could be calculated, for example the hash over the string <gardenid>-<seed object UID> prefixed bay the seed name.
The same is valid for the shoot, it should incorporate the gardenid and the UID of the shoot object. This assures that new shoots with the same name get a new id. Again the hash over the string <gardenid>-<shoot object id> prefixed by the shoot name and project can be used.
The prefix is always optional, because it is just for human readability, if the id is too long for a dedicated purpose.
These ids should always be properties in the cluster info object on the seed.
In general it would be very helpful if we could generally offer an info object in the kube-system namespace, that provides the identity of a cluster. For shoot clusters that could always be the shoot id. For soils we could fake this object by choosing a unique id based on the kube-system namespace object. It could always be provisioned by the seed controller, it there is not yet an info object (form the shoot creation).
This object could just be config map cluster-identity, that hosts a mandatory and other optional properties:

Property
Realm
Meaning

cluster-id
always
Id of the cluster.  This feature is independent of the gardener environment. So the DNS/Cert controller environment could fall back for its multi cluster support to read these ids instead of requiring manual consistent settings on the command line.
Gardener-aware controller could also evaluate the gardener-specific properties.

Okay, what do you think about proceeding concretely as follows:

Garden ID = garden-hash(uid of garden namespace in garden cluster)[:10], e.g. garden-a1b2c3d4e5
Seed ID = seed-hash(gardenID + uid of seed object)[:10], e.g. seed-u7i8o3j765a
Shoot ID = shoot-hash(gardenID + uid of shoot object)[:10], e.g. shoot-j8nbf7a4e2
Enhancing the extensions.gardener.cloud/v1alpha1.Cluster resource as follows:

apiVersion: extensions.gardener.cloud/v1alpha1
kind: Cluster
spec:
  shoot: ..
  seed: ..
  cloudProfile:
  project:
    <project-spec-without-members/owners>
  identities:
    garden: <gardenID>
    seed: <seedID>
    shoot: <shootID>

Ideally, the Seed and the Shoot object get to know about their IDs in the status as well:
a. core.gardener.cloud/v1beta1.Seed.Status.ID=<seedID>
b. core.gardener.cloud/v1beta1.Shoot.Status.ID=<shootID> (today, we have also uid (should be deprecated, probably), and technicalID (which is the shoot namespace, maybe it should be renamed to namespace?)

In general it would be very helpful if we could generally offer an info object in the kube-system namespace, that provides the identity of a cluster.

We already have a shoot-info configmap in the kube-system namespace of every shoot, e.g.:
apiVersion: v1
data:
  domain: my-domain.com
  extensions: shoot-cert-service,shoot-dns-service
  kubernetesVersion: 1.12.10
  maintenanceBegin: 000000+0100
  maintenanceEnd: 010000+0100
  nodeNetwork: <IP_ADDRESS>/16
  podNetwork: <IP_ADDRESS>/17
  projectName: my-project
  provider: aws
  region: eu-west-1
  serviceNetwork: <IP_ADDRESS>/17
  shootName: my-shoot
kind: ConfigMap
metadata:
  name: shoot-info
  namespace: kube-system

It could be enhanced with gardenID, seedID, and shootID fields as well.

cluster-id ,always , Id of the cluster. For shoot clusters this is the shoot id, for others it could be an id based on the UID of the kube-system namespace
Controller just requiring a cluster id always only read the cluster-id property. This feature is independent of the gardener environment. So the DNS/Cert controller environment could fall back for its multi cluster support to read these ids instead of requiring manual consistent settings on the command line.
seed-id- , seed , the id of the seed for a dedicated garden if the cluster is used as seed for this garden

This means, that you are proposing a seed-info configmap in the kube-system namespace in every seed as well, correct? However, can't these two be combined? And, instead of using the uid of the kube-system namespace, can't we use the uid of the Seed object again as cluster ID?
apiVersion: v1
data:
  seedID: <shootID (if the seed is a shoot as well), or uid of `Seed` object>
kind: ConfigMap
metadata:
  name: seed-info
  namespace: kube-system

WDYT?

Garden ID = garden-hash(uid of garden namespace in garden cluster)[:10], e.g. garden-a1b2c3d4e5
Seed ID = seed-hash(gardenID + uid of seed object)[:10], e.g. seed-u7i8o3j765a
Shoot ID = shoot-hash(gardenID + uid of shoot object)[:10], e.g. shoot-j8nbf7a4e2

Can we also just take the UID of the object we refer to in each ID, i.e. Shoot ID = shoot-<uid of shoot object>?
Kubernetes follows the ISO/IEC 9834-8 which says:

ISO/IEC 9834-8:2008 specifies the format and generation rules that enable users to produce128-bit identifiers that are either guaranteed to be globally unique, or are globally unique with a high probability.

I would prefer to not tightly bind the DNS eco-system to the gardener infrastructure. Therefore I proposed a more general config. map not necessarily bound to a shoot  or seed. Therefore the name cluster-identities. It should always contain a cluster id and can be enriched by any other kind of id as described above.
It also allows to handle combined shoot/seed clusters or even seeds for multiple gardens (if we want to support this some day). Fixed names like shoot-info or seed-info are not really suitable here.

Is it really a good idea to introduce a new gardenID? It would also be helpful to provide readable  IDs for seeds and shoots, e.g seed-aws-u7i8o3j765a and shoot--core--foobar--j8nbf7a4e2.
BTW, what do you think about introducing a singleton garden object which has a name (the landscape name) and maybe some other global attributes?
For existing landscapes, the id of the garden namespace will be used. For new gardens, we
can switch to the scheme garden--<random()[:10]>, e.g. garden-dev-r5i3t3j265h
apiVersion: core.gardener.cloud/v1beta1
kind: Garden
metadata:
  name: mylandscape
spec:
  id: <uuid>

Can we also just take the UID of the object we refer to in each ID, i.e. Shoot ID = shoot-?

Hm, yes, we should simply put the UID there. If users think it's too long they can cut themselves/hash again.

I would prefer to not tightly bind the DNS eco-system to the gardener infrastructure.

I don't see any connection between DNS and Gardener. This issue is about introducing IDs for the various layers, Garden, Seed, Shoot. Whether DNS controller use it or not is not related (yes, this was the trigger for this discussion, though, the solution is general).

Therefore the name cluster-identities. It should always contain a cluster id and can be enriched by any other kind of id as described above.

Your proposal from above also contains seed, shoot etc. I'm confused now... :( Maybe you can write down your concrete proposal how the IDs would look like in their config maps?

@MartinWeindel

Is it really a good idea to introduce a new gardenID? It would also be helpful to provide readable IDs for seeds and shoots, e.g seed-aws-u7i8o3j765a and shoot--core--foobar--j8nbf7a4e2.

Yes, makes sense, it's definitely helpful for operators and end-users if the Garden has a human readable name. Maybe a combination of both, the operator-provided name plus the UID of the garden namespace in the garden cluster?

BTW, what do you think about introducing a singleton garden object which has a name (the landscape name) and maybe some other global attributes?

IMO a Garden object is the wrong way to model this. This purports the possibility that it is possible to create multiple Garden resources in the  same garden landscape which definitely is not possible. Instead, it should be similar to the internal domain: If you provide it it's immutable unless you delete everything (only then you can change the domain). Similarly, the Garden ID can be provided and then never be changed unless all seeds/shoots are deleted. Today, the internal domain is stored in a configmap, no need for a dedicated object.

Your proposal from above also contains seed, shoot etc. I'm confused now... :( Maybe you can write down your concrete proposal how the IDs would look like in their config maps?

As I already explained twice, it is a general object that has mandatory and scenario based identity fields. it always has (independently of the gardener) a cluster-id field. It basically can be provided in any way and scenario. For gardener clusters it is maintained by the gardener, it uses the shoot id, if the cluster is a shoot. It can only be a shoot of one garden, therefore it is uniquely defined, even for seeds that are shoots (as described it always uses the shoot id). For non-shooted clusters in the gardener ecosystem (soils), the gardener (seed reconciler/gardenlet) defines the cluster-id (as explained it could be based on the uid of the kube-system namespace).
This general field can be consumed by any party just requiring a unique cluster identity.
Additionally scenario specific fields could be added, best in a qualified manner, for example shoot.gardener.cloud instead of just shoot-id and seed.shoot.gardener.cloud and seed.<gardenid>.gardener.cloud. This file is therefore modified by multiple controllers, but different properties.

For non-shooted clusters in the gardener ecosystem (soils)

There is no such terminology in the Gardener API. We have Seed and Shoot resources, that's it. So let's stick to those, please. What you mean is a cluster that will end-up as a Seed object as well. It doesn't/shouldn't matter where it is coming from (whether it was created as shoot or is coming from somewhere else).
Why should we take the UID of the kube-system namespace instead of the UID of the corresponding Seed object?

TBO, I would also prefer more human readable ids, but I see the problem with the length.

The IDs generated by Gardener should be human-readable, I guess. What a controller concretely does with them is up to it. If it uses the IDs in an environment with length restrictions then it has to cut them accordingly. We shouldn't care.
Still, I don't understand how you envision this should look like in the system. Can you please outline a concrete configmap example for both Seed and Shoot clusters? What shall Gardener generate?

There is no such terminology in the Gardener API. We have Seed and Shoot resources, that's it.

Sure we have soil clusters, that are no shoots, they do not have a cluster Id defined by their shoot identity. Therefore the cluster identity must be something else. We have two possibilities:

use the seed identity (taken from the garden cluster), but this would be inconsistent with the shooted seeds, here the shoot-id will be used as cluster id. Another problem would be the potential possibility to use a cluster as seed for multiple gardens. Therefore the seed id would be not a good idea.
use something else, like the uid of the cluster's kube-system namespace. Because the soil (per definition) is used as seed, the controller installing the cluster as seed, should set this cluster-id, if it is not yet set (for example: manually, or by the usage of the cluster by another garden). If it is used by another garden, also, the rule to create the cluster-id is the same, or, because the uid of the kube-system namespace is used, it is always guaranteed to be unique.

Meeting with @mandelsoft @MartinWeindel  and @rfranzke with the following result:

Garden Cluster:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-identity
  namespace: kube-system
data:
  cluster-identity: <landscape-name>-<uid-garden-namespace> # landscape-name is an immutable name for the garden landscape that is assigned by the garden operator

Seed Cluster:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-identity
  namespace: kube-system
data:
  cluster-identity: <uid-kube-system-namespace>

Shoot Cluster:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-identity
  namespace: kube-system
data:
  cluster-identity: <shoot.namespace>-<shoot-uid>-<garden-cluster-identity> # garden-cluster-id from 1. Garden Cluster

Each ConfigMap is created by Gardener. If a seed is a shoot at the same time, the cluster already has a cluster-identity and thus won't get another id during the seed registration.
Todo:

[ ] Implement possibility to configure a  (see 1.)
[ ] Implement ConfigMap creation through Gardener
[ ] Add shoot cluster-id (see 3.) to the shoot status

/area control-plane-migration
/assign @swilen-iwanow

In gardener there is no concept for landscape-name or landscape at all.
I'll suggest to remove those references.

We decided to remove the landscape-name and leave this to the Gardener operator/admin to decide what unique identifier to use.


Overflow warnings

During calls to optimize(), sometimes UserWarnings pop up:

/home/javdrher/.virtualenvs/gpflowopt/lib/python3.5/site-packages/GPflow/transforms.py:129: RuntimeWarning: overflow encountered in exp
result = np.log(1. + np.exp(x)) + self._lower

Typically this is quite harmless, if its really causing troubles its usually followed by a cholesky decomposition exception. However, those warnings mess up output. Specifically in documentation notebooks. I was thinking of silencing the warnings, any reason not to?

That particular overflow is harmless. I'd rather not silence warnings though: any ideas for how we might implement a more robust softplus?
Sent from my iPhone

On 25 May 2017, at 19:32, Joachim van der Herten<EMAIL_ADDRESS>wrote:
During calls to optimize(), sometimes UserWarnings pop up:
/home/javdrher/.virtualenvs/gpflowopt/lib/python3.5/site-packages/GPflow/transforms.py:129: RuntimeWarning: overflow encountered in exp
result = np.log(1. + np.exp(x)) + self._lower
Typically this is quite harmless, if its really causing troubles its usually followed by a cholesky decomposition exception. However, those warnings mess up output. Specifically in documentation notebooks. I was thinking of silencing the warnings, any reason not to?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

How about clipping x to some threshold? Where threshold = log(

Some improvement can be obtained with the log sum exp trick:
https://hips.seas.harvard.edu/blog/2013/01/09/computing-log-sum-exp/
Gave it a try, seems to solve forward very well, however I haven't solved the backward yet (now gives division by zeros)

Pre:

Post:

Seems to successfully suppress all warnings for the GPflowOpt tests for 2.7 and 3.5. Also tried the GPflow tests and they pass. @jameshensman interested in a PR for GPflow?

I think the correct solution is to replace
    def forward(self, x):
        result = np.log(1. + np.exp(x)) + self._lower
        # do not transform large numbers, they overflow and the mapping is exactly identity.
        return np.where(x > 35, x + self._lower, result)

with
    def forward(self, x):
        return = np.logaddexp(x, 0) + self._lower

Which does the "subtraction of max_float" for us.

Correct thats how I fixed forward, however that doesn't solve the backward transform in case y = self._lower which leads to a division by zero.
def backward(self, y):
        ys = np.maximum(y-self._lower, np.finfo(np_float_type).eps)
        return ys + np.log(1 - np.exp(-ys))

This applies the same idea used to implement np.logaddexp safely, but it also avoids np.log(0)

Good spot. How about this?
def backward(self, y):
        ys = y - self._lower
        return ys + np.log(-np.expm1(-ys))

Yikes I should read the numpy docs better. Cool, that passes the GPflow tests, however for GPflowOpt I get 30 errors:

InvalidArgumentError (see above for traceback): Input matrix is not invertible.
[[Node: MatrixTriangularSolve = MatrixTriangularSolve[T=DT_DOUBLE, adjoint=false, lower=true, _device="/job:localhost/replica:0/task:0/cpu:0"](Cholesky, unnamed.models.name.kern.K/mul)]]

Most output in the GPflowOpt tests have no output noise, hence the likelihood variance hits 1e-6 which might explain why I run into this corner case so much. Changing it into
def backward(self, y):
        ys = np.maximum(y-self._lower, np.finfo(np_float_type).eps)
        return ys + np.log(-np.expm1(-ys))

solves everything again. Between the cholesky errors this warning pops up:

/home/javdrher/.virtualenvs/gpflowopt/lib/python3.5/site-packages/GPflow/transforms.py:152: RuntimeWarning: invalid value encountered in log
return ys + np.log(-np.expm1(-ys))

I'm guessing np.expm1 is better for values near zero, however it seems to do something odd when actually encountering zero itself.

okay, great. PR this and I will merge it.